From opsec-bounces@ietf.org Mon Dec 1 18:03:02 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE4E03A6BAF; Mon, 1 Dec 2008 18:03:01 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981EF3A6AB9 for ; Mon, 1 Dec 2008 18:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ixpf0GZde4K for ; Mon, 1 Dec 2008 18:03:00 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id C07AA3A6A5B for ; Mon, 1 Dec 2008 18:03:00 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id mB222s0x019477 for ; Mon, 1 Dec 2008 20:02:54 -0600 (CST) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 20:02:54 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.27]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 07:32:51 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 2 Dec 2008 07:32:49 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196502356DBA@INEXC1U01.in.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-bhatia-manral-igp-crypto-requirements-03.txt Thread-Index: AclUIhPmxWxetFrdSlOTHz65Y17Fhw== From: "Bhatia, Manav \(Manav\)" To: X-OriginalArrivalTime: 02 Dec 2008 02:02:51.0129 (UTC) FILETIME=[14CBC690:01C95422] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-03.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi, We have posted a revised version of the "Cryptographic Authentication Algorithm Implementation Best Practices for Routing Protocols". This has been updated based on the feedback from the list and the IETF meet where it was suggested that we should (i) do away with the additional RFC2119 terms that we were using (SHOULD+, MUST-, etc) (ii) Change the tone of the draft so that its more like best practices rather than a diktat for protocol developers. Additionally, we have also included a small section on RIPng and OSPFv3 in this draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bhatia-manral-igp-crypto-requi rements-03.txt Would appreciate comments and feedback on the version! Cheers, Manav > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] > On Behalf Of Joel Jaeggli > Sent: Saturday, October 11, 2008 2.40 AM > To: opsec wg mailing list > Subject: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-00 > > We have at least some supporting opinion that this work should not be > pursued in opsec if it defines requirements. With a recommendations or > best practices focus it would be an appropriate addition. We should be > willing to entertain alternative views but I think that's the > current sense. > > joelja > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 2 21:07:53 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC713A6967; Tue, 2 Dec 2008 21:07:53 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8997B3A6967 for ; Tue, 2 Dec 2008 21:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlwcfSY8umVA for ; Tue, 2 Dec 2008 21:07:51 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 782403A68DB for ; Tue, 2 Dec 2008 21:07:51 -0800 (PST) Received: from [192.168.1.118] (c-24-130-16-195.hsd1.ca.comcast.net [24.130.16.195]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id mB357gIG097409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Dec 2008 05:07:43 GMT (envelope-from joelja@bogus.com) Message-ID: <4936141C.6020004@bogus.com> Date: Tue, 02 Dec 2008 21:07:40 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: Glen Kent References: <92c950310811292206w6eba091egc7fc7b49f4368509@mail.gmail.com> In-Reply-To: <92c950310811292206w6eba091egc7fc7b49f4368509@mail.gmail.com> X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV 0.93.3/8713/Tue Dec 2 19:59:31 2008 on nagasaki.bogus.com X-Virus-Status: Clean Cc: opsec wg mailing list Subject: Re: [OPSEC] housekeeping details part one - Security Assessment of the Internet Protocol version 4 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Glen Kent wrote: > Hi, > > I read the draft and it is without doubt a good piece of work. > > However, it makes several implementation specific recommendations, > i.e., checks that an implementation must perform before accepting a > fragmented packet, rate limiting IP options packets, and it goes on. > So, the question is: Is OPSEC the right home for this draft? Are the > members here qualified enough to make such recommendations? Isnt what > is described here, already done by several vendors (how do you > otherwise differentiate between different protocol implementation > qualities), etc.? Which comes down to documenting best practices. if it turns out that it has become common to check a certain protocol element for spurious values, for example checking the sequence number on tcp resets instead of just processing them, it doesn't require that we change the protocol in order to make (or amplify) a particular recommendation or requirement in a previous standard. Not all stacks are religiously conformant to begin with which is part the reason that some variation that you see... Liberal in what you accept and conservative in what you send isn't quite so helpful if what you happen to accept is crap. On the other hand we have abundant evidence of what happens when you get dangerously rigorous about accepting to little (when someone designs devices that happen to discard tcp ecn enabled packets because the bitfield wasn't in use when they were created. > Would an implementation not following one of the > recommendations given in this draft be non-compliant (i.e. if its to > become a proposed standard)? I'll interpret that as a preference against ps. > Glen > >> -----Original Message----- >> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >> On Behalf Of Joel Jaeggli >> Sent: Friday, November 21, 2008 10.41 AM >> To: opsec wg mailing list >> Subject: [OPSEC] housekeeping details part one - Security >> Assessment of the Internet Protocol version 4 >> >> I wanted to address this while the ideas are still fresh. I >> don't think >> we can really call the questions till I can get at least a skeleton of >> the minutes out and I'm only about halfway done but The major >> questions >> regarding: >> >> draft-gont-opsec-ip-security-01.txt >> >> are: >> >> Test consensus on list for accepting ip security document >> >> Areas for improvement in the document >> >> Need for cross area review >> >> BCP vs proposed standard >> >> Others? >> >> thanks >> joel >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 3 08:33:06 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6CD3A694C; Wed, 3 Dec 2008 08:33:06 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFF6A3A694C for ; Wed, 3 Dec 2008 08:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1CFeg92b+yH for ; Wed, 3 Dec 2008 08:33:05 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.184]) by core3.amsl.com (Postfix) with ESMTP id 9192B3A67ED for ; Wed, 3 Dec 2008 08:33:04 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id e6so818909gvc.15 for ; Wed, 03 Dec 2008 08:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=gR3zM8JegHQYOZC4PFrTL6j18DbG5OaKNcN8OcNfXrc=; b=pj4YYithI3pT1XYOd5ologIrSin1a2MRaVqK8q0AE8YGUOImhKH0xUfWJjHacS6yih WaSV0/ZIikRtHaSQcdRu8jjSfHYCbOlVMbVHfrcN0rlPhgBQSEqbWBpt2zoEZBJBI/pX GGPdPV20bJ/cNuEr2rQJuMVcMjnYxcWSUuxNM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=WPwu5V7G1Lzs5czEoLrB/6w3V0tpPMHWVlMWUBVHXX9tgVR8cNBW7ObbpzHQEQFJ72 rav7Q91grySLVcIGa0Fu/6znccvK+luQHmgX/fMN5jPZZXx4WYdj1Nb8FVqS+g+12gtf 30wT5F4IKMdA6XGzIZONxgGuK8SEo1IMqNtos= Received: by 10.103.165.18 with SMTP id s18mr6171648muo.124.1228321977415; Wed, 03 Dec 2008 08:32:57 -0800 (PST) Received: by 10.103.160.12 with HTTP; Wed, 3 Dec 2008 08:32:57 -0800 (PST) Message-ID: <92c950310812030832n59dfd5ael940e9269e2458635@mail.gmail.com> Date: Wed, 3 Dec 2008 22:02:57 +0530 From: "Glen Kent" To: "Joel Jaeggli" In-Reply-To: <4936141C.6020004@bogus.com> MIME-Version: 1.0 Content-Disposition: inline References: <92c950310811292206w6eba091egc7fc7b49f4368509@mail.gmail.com> <4936141C.6020004@bogus.com> Cc: opsec wg mailing list Subject: Re: [OPSEC] housekeeping details part one - Security Assessment of the Internet Protocol version 4 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On Wed, Dec 3, 2008 at 10:37 AM, Joel Jaeggli wrote: Hi Joel, > >> Would an implementation not following one of the >> recommendations given in this draft be non-compliant (i.e. if its to >> become a proposed standard)? > > I'll interpret that as a preference against ps. Yes, you certainly can. Glen > >> Glen >> >>> -----Original Message----- >>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >>> On Behalf Of Joel Jaeggli >>> Sent: Friday, November 21, 2008 10.41 AM >>> To: opsec wg mailing list >>> Subject: [OPSEC] housekeeping details part one - Security >>> Assessment of the Internet Protocol version 4 >>> >>> I wanted to address this while the ideas are still fresh. I >>> don't think >>> we can really call the questions till I can get at least a skeleton of >>> the minutes out and I'm only about halfway done but The major >>> questions >>> regarding: >>> >>> draft-gont-opsec-ip-security-01.txt >>> >>> are: >>> >>> Test consensus on list for accepting ip security document >>> >>> Areas for improvement in the document >>> >>> Need for cross area review >>> >>> BCP vs proposed standard >>> >>> Others? >>> >>> thanks >>> joel >>> _______________________________________________ >>> OPSEC mailing list >>> OPSEC@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsec >>> >> > > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 3 08:50:30 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5B028C104; Wed, 3 Dec 2008 08:50:30 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E7428C0EB for ; Wed, 3 Dec 2008 08:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYbtxyV+x-VZ for ; Wed, 3 Dec 2008 08:50:27 -0800 (PST) Received: from mail-gx0-f18.google.com (mail-gx0-f18.google.com [209.85.217.18]) by core3.amsl.com (Postfix) with ESMTP id 404EE28C0DF for ; Wed, 3 Dec 2008 08:50:27 -0800 (PST) Received: by gxk11 with SMTP id 11so563978gxk.13 for ; Wed, 03 Dec 2008 08:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=kd0C7QcSrRwe0wT3LFnW5R/BIorli6bYMjP0yFwcqoo=; b=p+70VigcQJlWz3eYG2IJBeD6sEhRW/xIM/bO5ypP2rXo/1Q3VsRu2yUBGwsbw5YekU N/IGaJlXQpo8ITUbI8KHuE6Lm8/7ygYoEJkD0uOWb2mk0DKC2szMoIUeFmsEiUpfYF1U hFebP9sLrUZ19oNVK8eiu+9H6D8i/9pQZIrCA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=lopfqX+E+xuds82eWJZLEoLjhDoQ0dGlW0Ze15D/yuBU4/9gdojJY21Knjt/Wgg9wX TdYoe7jfDYVsDHPuvIB1ZyY7EN15MgsjGwRW89HeWFV4n24Q4U/iky16OVPyt4/u0P3F N63haNVWcKLdmuObYIgo3LdLWP+KxVep9uY+o= Received: by 10.103.244.10 with SMTP id w10mr6185494mur.71.1228323015119; Wed, 03 Dec 2008 08:50:15 -0800 (PST) Received: by 10.103.160.12 with HTTP; Wed, 3 Dec 2008 08:50:15 -0800 (PST) Message-ID: <92c950310812030850q5c76f39ak1754c70dc216a354@mail.gmail.com> Date: Wed, 3 Dec 2008 22:20:15 +0530 From: "Glen Kent" To: "Bhatia, Manav (Manav)" In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356DBA@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356DBA@INEXC1U01.in.lucent.com> Cc: opsec wg mailing list Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-03.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi, Overall, the draft looks in good shape and i support it. One small comment though - I think their concern regarding the lack of security offered by MD5 for the routing protocols is misplaced. I am referring to the Introduction in that above draft. I agree that while it might be possible to spoof an acceptable MD5 digest, it is near impossible to spoof what might be an acceptable routing protocol packet with an acceptable spoofed digest.So, the authors might want to tone down their concern in that section! Glen On Tue, Dec 2, 2008 at 7:32 AM, Bhatia, Manav (Manav) wrote: > Hi, > > We have posted a revised version of the "Cryptographic Authentication > Algorithm Implementation Best Practices for Routing Protocols". > > This has been updated based on the feedback from the list and the IETF > meet where it was suggested that we should (i) do away with the > additional RFC2119 terms that we were using (SHOULD+, MUST-, etc) (ii) > Change the tone of the draft so that its more like best practices rather > than a diktat for protocol developers. > > Additionally, we have also included a small section on RIPng and OSPFv3 > in this draft. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bhatia-manral-igp-crypto-requi > rements-03.txt > > Would appreciate comments and feedback on the version! > > Cheers, Manav > >> -----Original Message----- >> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >> On Behalf Of Joel Jaeggli >> Sent: Saturday, October 11, 2008 2.40 AM >> To: opsec wg mailing list >> Subject: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-00 >> >> We have at least some supporting opinion that this work should not be >> pursued in opsec if it defines requirements. With a recommendations or >> best practices focus it would be an appropriate addition. We should be >> willing to entertain alternative views but I think that's the >> current sense. >> >> joelja >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Thu Dec 4 22:55:42 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5010B3A6B3E; Thu, 4 Dec 2008 22:55:42 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF7E3A6BCA for ; Thu, 4 Dec 2008 22:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDr9WTLwIGmm for ; Thu, 4 Dec 2008 22:55:39 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id DC83D3A6B3E for ; Thu, 4 Dec 2008 22:55:38 -0800 (PST) Received: from [192.168.1.118] (c-24-130-16-195.hsd1.ca.comcast.net [24.130.16.195]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id mB56swJ2064391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Dec 2008 06:54:59 GMT (envelope-from joelja@bogus.com) Message-ID: <4938D042.8090108@bogus.com> Date: Thu, 04 Dec 2008 22:54:58 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: Glen Kent References: <6D26D1FE43A66F439F8109CDD424196502356DBA@INEXC1U01.in.lucent.com> <92c950310812030850q5c76f39ak1754c70dc216a354@mail.gmail.com> In-Reply-To: <92c950310812030850q5c76f39ak1754c70dc216a354@mail.gmail.com> X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV 0.93.3/8722/Fri Dec 5 04:32:54 2008 on nagasaki.bogus.com X-Virus-Status: Clean Cc: opsec wg mailing list Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-03.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Glen Kent wrote: > Hi, > > Overall, the draft looks in good shape and i support it. > > One small comment though - I think their concern regarding the lack of > security offered by MD5 for the routing protocols is misplaced. I am > referring to the Introduction in that above draft. I agree that while > it might be possible to spoof an acceptable MD5 digest, it is near > impossible to spoof what might be an acceptable routing protocol > packet with an acceptable spoofed digest.So, the authors might want to > tone down their concern in that section! The general problem of being able to produce collisions with md5 digests does kind of make one inclined to deprecate their use when possible even when there are a limited set of circumstances under which it can be exploited. MD5 is used in lots of places and it will take a very long time to remove it from many of them... The law of unintended consequences says if I leave the MD5 library in my toolchain someone will eventually use it for some purpose for which it is totally unsuitable. I think description of the deprecation of md5 limitations in paragraph 3 of the introduction could use some help. one document that similarly addressed this subject I saw recently was: http://tools.ietf.org/html/draft-ietf-dnsext-tsig-md5-deprecated-01 the security considerations second of which describes to motivation fairly well. One concern I would express in the context of how this is done today is the persistence of the shared secret used to protect these sessions is measured in years notwithstanding the issues around storing things that persist that long an attacker with access to the packet stream can avail themselves of the opportunity to try to perform tradition brute force activities to generate the secret used to hash the data and generate the digest the salt in these protocols (eg tcpmd5) is sufficiently large to render rainbow tables infeasible... That's not really for this draft but it is worth thinking about longer term. > Glen > > On Tue, Dec 2, 2008 at 7:32 AM, Bhatia, Manav (Manav) > wrote: >> Hi, >> >> We have posted a revised version of the "Cryptographic Authentication >> Algorithm Implementation Best Practices for Routing Protocols". >> >> This has been updated based on the feedback from the list and the IETF >> meet where it was suggested that we should (i) do away with the >> additional RFC2119 terms that we were using (SHOULD+, MUST-, etc) (ii) >> Change the tone of the draft so that its more like best practices rather >> than a diktat for protocol developers. >> >> Additionally, we have also included a small section on RIPng and OSPFv3 >> in this draft. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-bhatia-manral-igp-crypto-requi >> rements-03.txt >> >> Would appreciate comments and feedback on the version! >> >> Cheers, Manav >> >>> -----Original Message----- >>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >>> On Behalf Of Joel Jaeggli >>> Sent: Saturday, October 11, 2008 2.40 AM >>> To: opsec wg mailing list >>> Subject: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-00 >>> >>> We have at least some supporting opinion that this work should not be >>> pursued in opsec if it defines requirements. With a recommendations or >>> best practices focus it would be an appropriate addition. We should be >>> willing to entertain alternative views but I think that's the >>> current sense. >>> >>> joelja >>> _______________________________________________ >>> OPSEC mailing list >>> OPSEC@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsec >>> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Fri Dec 5 04:27:16 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 238713A6C00; Fri, 5 Dec 2008 04:27:16 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A91973A6C67 for ; Fri, 5 Dec 2008 04:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Yc15akZXpiW for ; Fri, 5 Dec 2008 04:27:13 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 682963A68BF for ; Fri, 5 Dec 2008 04:27:13 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so2009841yxg.49 for ; Fri, 05 Dec 2008 04:27:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=GSyl1jbZTxYAwT+V68oSC71Fv9v1A1YT8lPg5WRXKPU=; b=XZbypnJc6b8BvkyY4LQoFlP6CqLH1j7T6PB3Fei9X3Oge/xX2c6ioLca3hB/KSyJE7 8WldK1/Zxsl+C5JVU5yQ6SuR/cq14VzUncDlG2k0Cw203IL0kF3hKdRUyt6S3o+5uTG+ UcXYHB4BbSriMuU67bHaYDRDcX+3Jnf7YHFVw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=WxLOEnkiJliHAzobaW66ZpxpsI4+vGPxb8iKkAbyJf9yT18Yndx4YzzoCujcPOs5bO 8BEg/A+u3BGxYVlngaCn9RgxiC5XXwB71tWh3Nm6mVQbKtY+kPXiLfgs6v7YgDz0wUjZ KyRoZgcr/bxj4j2W/PoAQ6P1lKqp73MNFmvKg= Received: by 10.100.189.10 with SMTP id m10mr8638766anf.118.1228480028615; Fri, 05 Dec 2008 04:27:08 -0800 (PST) Received: by 10.100.153.20 with HTTP; Fri, 5 Dec 2008 04:27:08 -0800 (PST) Message-ID: <75cb24520812050427mbc1942cuf7c7d7eb424463b@mail.gmail.com> Date: Fri, 5 Dec 2008 07:27:08 -0500 From: "Christopher Morrow" To: "Joel Jaeggli" In-Reply-To: <75cb24520812050425p1a52602bydb18e3878d540eb@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356DBA@INEXC1U01.in.lucent.com> <92c950310812030850q5c76f39ak1754c70dc216a354@mail.gmail.com> <4938D042.8090108@bogus.com> <75cb24520812050425p1a52602bydb18e3878d540eb@mail.gmail.com> X-Google-Sender-Auth: 4a1cf5852b7752db Cc: opsec wg mailing list Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-03.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org (initially sent with wrong src-addr, apologies) On Fri, Dec 5, 2008 at 7:25 AM, Christopher Morrow wrote: > On Fri, Dec 5, 2008 at 1:54 AM, Joel Jaeggli wrote: >> Glen Kent wrote: >>> Hi, >>> >>> Overall, the draft looks in good shape and i support it. >>> >>> One small comment though - I think their concern regarding the lack of >>> security offered by MD5 for the routing protocols is misplaced. I am >>> referring to the Introduction in that above draft. I agree that while >>> it might be possible to spoof an acceptable MD5 digest, it is near >>> impossible to spoof what might be an acceptable routing protocol >>> packet with an acceptable spoofed digest.So, the authors might want to >>> tone down their concern in that section! >> >> The general problem of being able to produce collisions with md5 digests >> does kind of make one inclined to deprecate their use when possible even > > to be able to make a collision with content worthwhile to the problem > space seems very limited, knowing the key and spitting out a packet on > the wire which is signed would be far simpler. > >> when there are a limited set of circumstances under which it can be >> exploited. MD5 is used in lots of places and it will take a very long >> time to remove it from many of them... The law of unintended >> consequences says if I leave the MD5 library in my toolchain someone >> will eventually use it for some purpose for which it is totally unsuitable. >> > > I agree that longer term migrating away so it's not re-used in a bad > place/way is fine... I think people often stop with: "Md5 has > collisions so we shouldn't use it" before asking if making a collision > in their circumstances is relevant or possible in a timely fashion. > >> I think description of the deprecation of md5 limitations in paragraph 3 >> of the introduction could use some help. >> >> one document that similarly addressed this subject I saw recently was: >> >> http://tools.ietf.org/html/draft-ietf-dnsext-tsig-md5-deprecated-01 >> >> the security considerations second of which describes to motivation >> fairly well. >> >> One concern I would express in the context of how this is done today is >> the persistence of the shared secret used to protect these sessions is >> measured in years notwithstanding the issues around storing things that >> persist that long an attacker with access to the packet stream can avail >> themselves of the opportunity to try to perform tradition brute force >> activities to generate the secret used to hash the data and generate the >> digest the salt in these protocols (eg tcpmd5) is sufficiently large to >> render rainbow tables infeasible... >> > > the secrets stay the same because someone though adding md5 auth to > routing protocols was a good thing (which is probably is in some/many > cases) but stopped there. There was never any thought put into the > operations of the system, just the 'security'... Key rollover/change > is significantly painful that pretty much no one actually does it. > > -Chris > >> That's not really for this draft but it is worth thinking about longer term. >> >>> Glen >>> >>> On Tue, Dec 2, 2008 at 7:32 AM, Bhatia, Manav (Manav) >>> wrote: >>>> Hi, >>>> >>>> We have posted a revised version of the "Cryptographic Authentication >>>> Algorithm Implementation Best Practices for Routing Protocols". >>>> >>>> This has been updated based on the feedback from the list and the IETF >>>> meet where it was suggested that we should (i) do away with the >>>> additional RFC2119 terms that we were using (SHOULD+, MUST-, etc) (ii) >>>> Change the tone of the draft so that its more like best practices rather >>>> than a diktat for protocol developers. >>>> >>>> Additionally, we have also included a small section on RIPng and OSPFv3 >>>> in this draft. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-bhatia-manral-igp-crypto-requi >>>> rements-03.txt >>>> >>>> Would appreciate comments and feedback on the version! >>>> >>>> Cheers, Manav >>>> >>>>> -----Original Message----- >>>>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >>>>> On Behalf Of Joel Jaeggli >>>>> Sent: Saturday, October 11, 2008 2.40 AM >>>>> To: opsec wg mailing list >>>>> Subject: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-00 >>>>> >>>>> We have at least some supporting opinion that this work should not be >>>>> pursued in opsec if it defines requirements. With a recommendations or >>>>> best practices focus it would be an appropriate addition. We should be >>>>> willing to entertain alternative views but I think that's the >>>>> current sense. >>>>> >>>>> joelja >>>>> _______________________________________________ >>>>> OPSEC mailing list >>>>> OPSEC@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/opsec >>>>> >>>> _______________________________________________ >>>> OPSEC mailing list >>>> OPSEC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/opsec >>>> >>> _______________________________________________ >>> OPSEC mailing list >>> OPSEC@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsec >>> >> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Fri Dec 5 07:00:29 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E3C3A6C84; Fri, 5 Dec 2008 07:00:29 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F923A6C80 for ; Fri, 5 Dec 2008 07:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.806 X-Spam-Level: X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjgczyqrKJAR for ; Fri, 5 Dec 2008 07:00:27 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 3BA843A6C7E for ; Fri, 5 Dec 2008 07:00:27 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mB5Exaeq001675; Fri, 5 Dec 2008 09:00:17 -0600 (CST) Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Dec 2008 09:00:13 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.27]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Dec 2008 20:30:10 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 5 Dec 2008 20:29:32 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD42419650240AF59@INEXC1U01.in.lucent.com> In-Reply-To: <92c950310812030850q5c76f39ak1754c70dc216a354@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-03.txt Thread-Index: AclVZ64O+SPbP9vORTOS85+wTB1TZwBf/Xgw References: <6D26D1FE43A66F439F8109CDD424196502356DBA@INEXC1U01.in.lucent.com> <92c950310812030850q5c76f39ak1754c70dc216a354@mail.gmail.com> From: "Bhatia, Manav \(Manav\)" To: "Glen Kent" X-OriginalArrivalTime: 05 Dec 2008 15:00:10.0328 (UTC) FILETIME=[2B2A0580:01C956EA] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: opsec wg mailing list Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-03.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Glen, Thanks for the comments. > > One small comment though - I think their concern regarding the lack of > security offered by MD5 for the routing protocols is misplaced. I am > referring to the Introduction in that above draft. I agree that while > it might be possible to spoof an acceptable MD5 digest, it is near > impossible to spoof what might be an acceptable routing protocol > packet with an acceptable spoofed digest. I agree and we do mention this in the draft! :-) > So, the authors might want to > tone down their concern in that section! We have the following text in the Introduction. "It should however be noted that these attacks may not necessarily result in direct vulnerabilities in Keyed-MD5 as used in the routing protocols for authentication purposes, because the colliding message may not necessarily be a syntactically correct protocol packet. However, there is a need felt to move away from MD5 towards more complex and difficult to break hash algorithms." Is there something specific that you are looking for? Cheers, Manav _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Fri Dec 5 19:27:07 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D57B3A682A; Fri, 5 Dec 2008 19:27:07 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF8D3A682A for ; Fri, 5 Dec 2008 19:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIQ2r+YMIKrg for ; Fri, 5 Dec 2008 19:27:04 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 913313A6811 for ; Fri, 5 Dec 2008 19:27:04 -0800 (PST) Received: from [192.168.1.118] (c-24-130-16-195.hsd1.ca.comcast.net [24.130.16.195]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id mB63QpVi017561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 Dec 2008 03:26:56 GMT (envelope-from joelja@bogus.com) Message-ID: <4939F0FA.5030004@bogus.com> Date: Fri, 05 Dec 2008 19:26:50 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: Christopher Morrow , opsec wg mailing list References: <6D26D1FE43A66F439F8109CDD424196502356DBA@INEXC1U01.in.lucent.com> <92c950310812030850q5c76f39ak1754c70dc216a354@mail.gmail.com> <4938D042.8090108@bogus.com> <75cb24520812050425p1a52602bydb18e3878d540eb@mail.gmail.com> In-Reply-To: <75cb24520812050425p1a52602bydb18e3878d540eb@mail.gmail.com> X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV 0.93.3/8728/Fri Dec 5 15:44:27 2008 on nagasaki.bogus.com X-Virus-Status: Clean Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-03.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Christopher Morrow wrote: > the secrets stay the same because someone though adding md5 auth to > routing protocols was a good thing (which is probably is in some/many > cases) but stopped there. There was never any thought put into the > operations of the system, just the 'security'... Key rollover/change > is significantly painful that pretty much no one actually does it. solving this problem is safely outside the scope of our working group. ;) That said one could imagine adding some additional element to the shared secret that could be derived at startup of the protocol session (wouldn't work for broadcast) like current time at transmission of the first packet, that would make the actual shared secret on the wire only relevant for the duration of a single session, (it would require clocks have a certain minimum amount of syncronization) without further negotiation. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sun Dec 7 17:42:51 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E417B3A69CA; Sun, 7 Dec 2008 17:42:51 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D383A69DA for ; Sun, 7 Dec 2008 17:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60L0XuGFUDTQ for ; Sun, 7 Dec 2008 17:42:49 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 7AD3B3A686A for ; Sun, 7 Dec 2008 17:42:48 -0800 (PST) Received: from [192.168.1.118] (c-24-130-16-195.hsd1.ca.comcast.net [24.130.16.195]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id mB81ge1P033565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 8 Dec 2008 01:42:40 GMT (envelope-from joelja@bogus.com) Message-ID: <493C7B90.8060501@bogus.com> Date: Sun, 07 Dec 2008 17:42:40 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: opsec wg mailing list X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV 0.93.3/8730/Sun Dec 7 06:03:03 2008 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] minutes part 1 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Sorry the minutes were something of a hash so I greatly expanded them with the assistance of the recording. the downside being they took longer to produce. this is part one which covers the first two presentations. part the second is underway opsec minutes introduction Joel Jaeggli agenda bashing rough outline status update on working group Dublin consensus affirmed on working group charter ICMP filtering and blackhole filtering update documents considered basis of new work 3 active documents now an improvement over zero additional interesting work, but we've gone from no longer on it's last last legs to having interesting work to do. Fernando presenting 2 documents, one accepted in Dublin the other new work brought from outside. Fernando Gont Security Assessment of the Internet Protocol version 4 First time this document has be presented at an IETF meeting Problem statement no single document that presents the security implications of the ipv4 protocol in total. considering there are no official documents that discusses this problem in total with the result that new implementations repeat them. In 2005 the UK CPNI decided to change this state of affairs by starting a project that was a project to study the security implications of the ipv4 protocol implementations. one of the goals of this project was to provide a bibliography as to what was being done about some of the problems that were found. analyse the security implications of the ipv4 header fields and ipv4 mechanisms. As a result the document produced is ~60 pages with close to 100 references to specifications and relevant papers Published as part of CPNI's process, now we want to take the results to the IETF so that these results are part of the official documents. been working on this document for almost two years. Many vendors involved in review in CPNI We think this document is important to the IETF, fills a gap Do you think this document should be adopted as a WG item. Richard Graveman It's such a pretty document why do you want to publish an ugly text version (slightly in jest) Is the IETF going to help make this better? Fernando some time involved, but it's important that the IETF document train reflects work in this space. unknown alternative versions are possible Joel XML version can generate text version Ron Bonica Not so much about format, we specified IP, this is where IP lives we have a lot of inherited wisdom, but it's really not documented in one place we should do it here. Richard Ron I agree with you 100% and format was a jest. the point I'm trying make is are we being asked to rubberstamp this report or take the wisdom that we have as part of this community and see if we agree and maybe we can improve it. Fernando The reason it was published as an ID was to ask for comments and incorporate comments. could differ from CPNI Document. Chris Lonvick This came up in security directorate lunch and there should be enough people to review it. Joel Ask for cross area review if we accept it. probably valuable input that could be added to it. Richard given those statements I'm fine with it. Fernando In addition to what Joel said the document is is meant to be updated from the version that CPNI published. Ron Informational vs BCP? if you're going to ask for cross area review then BCP might be the way to go. Fernando could even go for proposed standard but that's a harder hurdle for the document to get over Ron at this point it doesn't make a difference. if you want it to be BCP it needs an IETF last call Fernando may not matter what category the document is in. the high order bit is that it should be published and that the high order bit is that it should be published and the IETF should provide advice Joel thanks, you have another document obviously but presuming we have enough people in the room who have read it we should be able to ask if there's consensus to adopt as a working group document. Ruddinger Volk Sorry for being spoil sport, my understanding is that in opsec we are concerned with the operational security. We have boxes that might suffer from the problems that you are discussing but I am concerned assuming that the people who are adequate for discussing the implementation of IP are exactly the same as those working on it's operational security. Joel I think if we were doing implementation that would be more of a problem then if we were attempting to a get a read of how it works today. You probably don't want to look at a document that came out of here for implementation advice for a Protocol. you might look to a document that came from here for guidelines as to how to use it. the former is clearly out of scope for this wg. do you agree with that reading? Ruddinger I would think so, but not having read the document I cannot point out that it's sounds like it is implementation details. Fernando some of the elements cover implementation details but much of the stuff covers how you use the protocols for operations. sometimes for example you might build an ids signature around it Joel for example this document references rfc 815, in doing so it doesn't suppose to tell you how you put together ip datagrams but rather tha implications of what you already have. That may be a semantic distinction, but if it is it is a fairly big one. anyone else have commentary? how many people have read it for reference (about 4 hands). I don't think that's enough in this room to ask for consensus to take it as a working group document but we can take that but to the list. and we can flag these issues as things the we need to address in deciding if this is a working group document. my personal opinion is that part of the problem we actually face here is that no one has actually done a document quite like this is that scope is larger than a particular working group except maybe the security area as a whole, so the fact that we have a willing victim to produce a document that's this big is something that we should take advantage of if it will produce a document that actually useful. If we do decide to accept this document we should seek input for the security area. We'll take this question to the list Fernando The next document is the icmp filtering document There were a couple of issues that I had written on the mailing list a couple of months ago they were mostly about the structure of the document. right now for each of the icmp messages we have 4 sections. message type usage threats - security implications operational impact if blocked. It's a big document We wanted to get agreement on the structure of the document, very little input on the list, but we want agreement before we update the document. So that in three or four months somebody doesn't request changes to the document structure. Some discussion of expansion of blocking to cover the scenarios of blocking messages from a device to a device or through a device. We'd like to agree on all these issues before it's to late richard I'll make a suggestion for shortening the document, 4443 my comments are all about v6. rfc 4443 specifics some icmpv6 messages but not all of them. you'll find the iana page references 10 other rfcs. So if you're trying to filter icmpv6 you're going to find a lot of things that this document never consdiers. that would be a huge amount of extra work that would delay the document quite a bit. on the other hand to the rescue the is another working group in this area (v6ops) that wrote an rfc called 4890 recomendations for filtering icmpv6 and that's not referred. So my suggestion would be to rename this document recommendations for filtering icmpv4 take all the icmpv6 stuff and go match that material with 4890 and see if 4890 needs to be revved (in a separate document) Fernando Right now there are lots of sections that still have to be populated. Richard It doesn't have a placeholder for these other messages it pretends that it has them all. I sent you an email 6 months ago and on the list 3 months ago mentioning this topic. I have strong problems with the icmp6 section because it is incomplete. Fernando The document is incomplete because the structure has yet to be determined I don't want to get several months down the road and decide that the structure needs to be changed. I think it was Donald Smith who provided the from to or through language. So we are not actually arguing about the contents, so I don't want to waste a lot of cycles until the high order bit (structure) has been set. Ron Bonnica (as an individual) Richard reminded me of something interesting. if you go to that same IANA page you'll find a bunch of really goofy icmp messages that nobody ever uses. that are defined in some really strange drafts. Joel Can we make normative references to the iana assignment pages. Ron They always point you back to some other rfc that noone has ever read. At least for v4 theres a small additional task to take care of... For v6 there are two distinct questions Have we hit all the message? probably with a little extra work we could at least put in boilerplate to get all the messages The next question is do we have the same level of operational experience with v6 as we do with v4? with v4 we're ready to publish this document as a bcp with an awful lot of authority. With v6, maybe informational. So that might actually be argument for splitting the documents into a v4 bcp and a v6 one informational that needs to be socialized in v6ops until enough people have deployed v6 networks so that we really do understand security issues that will appear? Joel (rhetorically) yeah does anyone actually have operational experience with fmip v6? that's the most recent addtion to the iana ipv6 messagee types. I think there are some more icmpv6 message types that are in the queue that haven't arrived yet, and speculation as to how they're going to be abused once deployed is probably a little early. There's some interesting feedback here: I get the impression that people are not unhappy with the existing structure. Richard 4890 takes a different approach one would at least want to know why one approach was chosen over the other. The approach in 4890 is that some messages mush always be blocked, messages that should never be blocked, and judgement cases. it takes the point of view of the filter, sort of the inverse structure Talk to the author of the other as to why that tack was taken. Joel One of the lessons to take from ipv4 is that even if you tell someone never to block a particular kind of ICMP message they will choose to do that anyway. So, the tone that this document takes is that when you shoot yourself in the foot, this is what is going to happen. that is a more realistic tack to take in v4 because we know people are going to filter all of these because they do. whereas in v6 we should be saying, when you do your implementation you really shouldn't be filtering these because you need them to work. 10 years from another document will come along that says when you shoot yourself in the foot with icmpv6 this is how youo did it. Richard yeah another reason to separate. when I read the document the v4 section is much better. Joel This is good criticism. it produces some actionable exercises. either the relationship to icmp6 messages in totality needs to be clarified. Or perhaps that section needs to be split off. I don't think that would produce dramatically more work. Philosophically it makes it somewhat incomplete since it doesn't deal with the totality of icmp but maybe that becomes a second draft. I think we can pose that question to the list and see if there as strong opinions. Fernando There is is the question of from to or through. Joel ok You're right and putting more meat on the document is dangerous without clarifying that Fernando we'd like feedback on the structure before spending more cycles on filling in sections. Joel the criticism of whether it is incomplete vs whether v4 and v6 are treated simultaneously is a fairly high level meta question Danny Macpherson I think it's fine to not specify what to do with some messages. I think it's worth having a table to which lists the messages we have recomendations for and those which we do not. To Rons comment I think It's a terrible idea to say filter these things because we don't think anyone uses them. In agreement with don smiths distinction between end and intermediate systems. I would also note that the icmp6 document richard was referring to is icmp6 considerations in firewalls. which is a middlebox but it is not a router. Ron In my experience most operators filter all icmp messages except for the ones that they know they need. Danny In securing the control plane they do but not across the network else. Ruddinger I think I can confirm. But default firewall policy tends to allow only things we know about. Joel That certainly applies to controll plane processors Danny So that's the distinction that's iportant the distinction between to the device and through the devices in the network. Joel I think that speaks to the host nature of control plane processors, when you have host exposure you apply policy there. With control plane processors you have basically every kind of resource starvation opportunity imaginable as long as you're not filtering. Melinda Shore In terms of filtering the people who are throwing all kinds of ICMP messages, the further you go towards the edge of the network the more likely you are to see that. certainly you see that in enterprise networks The thing that concerns me about the recommendation is that it's kind of meaningless security practice and I'm not sure we want to support that. Joel That's the nature of responding to things, like oh you decided to filter path mtu messages, or you decided to rate limit them because they were causing to you resource issues. That doesn't help it's the same as breaking them completely. I think that's the part of the document that works quite well at this point is pointing out what happens when you do that. I'm not sure that it needs to address that down to the level of through vs delivery to a particular system. The consequences of filtering it are the same. Fernando So you're basically saying that the document can stay as is? Joel yeah I think so, I mean I think we should probably test the mailing list for that. my sense is that we already deal with why it is that people were choosing to filter something or what they got by not filtering it. Is that seen as sufficient? Danny I think so, but Don has a point people do all sorts of things in the name of control plane policing but that's perfectly fine but it's different than through those middle boxes to end systems. Maybe have a security considerations section say that people operating operating middle-boxes may have different policy or employ a more explicit policy than open end-to-end networks. I'll take a stab at kicking this topic off or sending a little bit of text. Fernando So, you don't think we need different subsections, but rather just a statement in the document? Danny I think it's fine to have those considerations in there but it's going to vary as to what policy is appropriate for protecting the control plane. if you're going to make that distinction it going that have different implications on different devices. Fernando ok Merike Keio I agree with Danny. I've read the v6 document and it's makes my head spin who to from how what when. Really enumerating what they're used for and have some more general statement you know be careful of this but not have all the different considerations. Richard A lot of the impetous for filtering icmp came from icmp messages of inconvenient length turned certain operating systems displays blue. Ron When I first though about the statement from to or through I though it was overkill until the misunderstanding that danny and I just had. If you are an endpoint the filter that ruddinger suggested, filter everything except what I know I need is reasonable. if you are a transit router the filtering policy danny suggest is reasonable.... Joel Right it's good to have that distinction and consider that. knowing that you're going to shoot yourself in the foot by breaking say path mtu discovery is something that you will choose to do in order to protect a resource just as you will with a firewall. This is the implication of blackholing that packet and I'm comfortable with that so I'm going to do it anyway. Ron I can think of one you might want to block if you're an endpoint but let through if you're a router. Danny Even if you filter things to you, as part of control plane policing. That doesn't mean you'll break path mtu discovery though the box. Joel Right my control plane processor is only talking to things that are explicitly configured. So, I decide that I'm throwing out all sorts of icmp messages, because my default policy is deny and I only open it for things I need to connect to. Danny Yeah I understand your point. Fernando that's it Joel So, this is already a working group document, I have notes on things we need to take back to this list so I think we should move on to our next speaker. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 9 14:55:12 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77CA13A6B0E; Tue, 9 Dec 2008 14:55:12 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1744D3A6B0E for ; Tue, 9 Dec 2008 14:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+L0pYJWcj6C for ; Tue, 9 Dec 2008 14:55:08 -0800 (PST) Received: from mail-bw0-f13.google.com (mail-bw0-f13.google.com [209.85.218.13]) by core3.amsl.com (Postfix) with ESMTP id 6127C3A6A5E for ; Tue, 9 Dec 2008 14:55:08 -0800 (PST) Received: by bwz6 with SMTP id 6so471459bwz.13 for ; Tue, 09 Dec 2008 14:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=cWLpE2zOiXcRy2fp6S9Ia46z3yLaCDdMCoy9UuBJQXE=; b=MSjWfgdTT021me6ohfrKSt9vQPTzYVylvRkTP3tvDsaWt8D636CptgE91/kFkJHcYg FalzZNwYMWVFqtlrGlkulEDRuv02J0R22q3a0DWUqe4kDQKYo8IMmIC8aGVTG54HaCvg HUMTRGUzyk1jf7f9jhg2PjWKlT3NaUOSvpfps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=RXbkKbuByIaUj9Msy7sRGnpift/jSV1kf3FfLuYYwyiP5aiz4zqpU5HkRM2bd70fHb 0U26ekr3Nner9LVfpvcR1o0x0/3HQ0almETcQVcyfbOuRAh76JLYEa3eO6MPI7f6Ly7D MHWngQhuDJnVyvzDBqh9RsjDj/V5Hd4zJ0J2M= Received: by 10.103.93.18 with SMTP id v18mr269495mul.111.1228863296872; Tue, 09 Dec 2008 14:54:56 -0800 (PST) Received: by 10.103.160.12 with HTTP; Tue, 9 Dec 2008 14:54:56 -0800 (PST) Message-ID: <92c950310812091454u5fc4471dg130563a8bb52c5da@mail.gmail.com> Date: Wed, 10 Dec 2008 04:24:56 +0530 From: "Glen Kent" To: "Bhatia, Manav (Manav)" In-Reply-To: <6D26D1FE43A66F439F8109CDD42419650240AF59@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356DBA@INEXC1U01.in.lucent.com> <92c950310812030850q5c76f39ak1754c70dc216a354@mail.gmail.com> <6D26D1FE43A66F439F8109CDD42419650240AF59@INEXC1U01.in.lucent.com> Cc: opsec wg mailing list Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-03.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi, > We have the following text in the Introduction. > > "It should however be noted that these attacks may not necessarily > result in direct vulnerabilities in Keyed-MD5 as used in the routing > protocols for authentication purposes, because the colliding message may > not necessarily be a syntactically correct protocol packet. However, > there is a need felt to move away from MD5 towards more complex and > difficult to break hash algorithms." Sorry, i missed this. > > Is there something specific that you are looking for? No, not really. Glen. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Thu Dec 11 06:30:01 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5F13A6A6F; Thu, 11 Dec 2008 06:30:01 -0800 (PST) X-Original-To: opsec@ietf.org Delivered-To: opsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5687E3A6A6F; Thu, 11 Dec 2008 06:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081211143001.5687E3A6A6F@core3.amsl.com> Date: Thu, 11 Dec 2008 06:30:01 -0800 (PST) Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-efforts-09.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: opsec-bounces@ietf.org Errors-To: opsec-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 Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : Security Best Practices Efforts and Documents Author(s) : C. Lonvick, D. Spak Filename : draft-ietf-opsec-efforts-09.txt Pages : 36 Date : 2008-12-11 This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-efforts-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-opsec-efforts-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-11062544.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec --NextPart-- From opsec-bounces@ietf.org Sat Dec 13 11:07:11 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACD7B3A68EF; Sat, 13 Dec 2008 11:07:11 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BDE13A68EF for ; Sat, 13 Dec 2008 11:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWElv5sOPU60 for ; Sat, 13 Dec 2008 11:07:09 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 69C183A6868 for ; Sat, 13 Dec 2008 11:07:08 -0800 (PST) Received: from [172.168.1.103] (adsl-76-205-25-132.dsl.pltn13.sbcglobal.net [76.205.25.132]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id mBDJ6aZn089670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 13 Dec 2008 19:06:56 GMT (envelope-from joelja@bogus.com) Message-ID: <494407B4.4040607@bogus.com> Date: Sat, 13 Dec 2008 11:06:28 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: opsec wg mailing list X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV 0.93.3/8751/Sat Dec 13 03:47:53 2008 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org This is the transcript from the second two presentations and the wrap-up joel jaeggli Gaurava Agarwal will speak to manav's documents. There's two of them, I believe that both of these documents originated in rpsec and come looking for a home. It was pretty clear from the outset, that the spec crypt issues deals with a straight architectural problem. We got consensus on the list to accept that one on 10/10 with little or no opposition. The second document dealt with requirements so there is some opposition to the doucment in it's current form. feedback on the list was favorible to the document but only as a set of recomentations or a bcp rather than as a set of requirements for protocol implmentors. Both of these documents need feedback I'll let him speak to them. Guarav Agarwal The first document I'm going to speak to is issues with existing cryptographic methods in routing protocols I'm going to give an overview of routing protocol security and what is missing. ... There is some issues with how we use authentication currently in routing protocols. document is supposed to list those concerns. covers ospf isis and rip. OSPF cryptographic sequence number spoofing or replay Need to move from md5 to stronger crypto. Keys shared across the broadcost domain, need to move to a stronger key identifier For ospfv3 relies on ipsec, because manual key sequence number, replay protection cannot be used. It's not the authentication header that's the problem it's due to the multicast nature. ISIS, md5 but no sequence number not notion of keyid for pdu key must be validated. Need to update from md5 ripv2, no authetication of ip or udp headers . can change source address and reciver will still think it's a valid neighbor. Comments? Bill Atwood You can add pim sm to the list. We need a distributed keyserver and the ospf guys need it even more than we do. gathering together a group of people to identify the needs and go and beat on msec. Jeff haas This document is a nice problem statement of a number of protocols... Any intentions in this working group to go beyond this? Gaurav Just to list the problems in current crypto algorithms. Jeff the reason i ask this question is being the co-chair of another group that is affected by this (bfd). Manav and Vishwas have be bringing these to each working group, but a place that collects all these things is good the problem is this doucment tries to be everything by gathering them all in one spot, the contents of this document are a manifest of work that needs to be done at a per working group level. It may make more sense to have them be individual doucments instead of thrashing the docuemnt everytime more work is added. Rich Graveman I agree with the previous comment. after I read it "I just read a guide to hacking cryptographically protected routing protocols" I think we need to move for what's wrong to the fix side, I will also echo previous comment, the multiparty key distribution problem is one of the less tractable problems. we can fix the hashed md5 problem. It's not routing protocols alone but the rsvp people are tackling the same thing, well similar enough. joel jaeggli (as participant) I think one of the issues with this document is that the solution space is out of scope for this particular working group. we not going to go out and do implementations for these problems, on the other hand we have problems with the protocols that we use, and that component bring it here as opposed to say in rpsec. you're not going to solve the key distribution problem here. I think it's effective to bundle these up and survey the space. The divdie and conquer approach may still be required because you can't solve all these problems in one place. we can do this part of the work, and maybe we can help with some of these problems. Sheela Rowles We are exploring fullfilling the need for rsvp but in the early stage of exploring the options (and this is happening in msec) Gaurav Second draft, minimum cryptograhic requirements. the fact is cryptographic algorithms continue to be attacked. we need to keep track of this. the idea of this document is to keep modifying it but to track the minimum requirements for interoperability. Requirements involve should- must- may+ carry values for future inclusion or removal. Tomorrow if a new scheme is introduced we'll need to rev this document. md5 must-, you need it, in the future it won't be a must requirement other requirements will take precident. Ron Bonnica In the last slide did I see a must minus. as an implementer how should I interpret this? Gaurav As a requirement now but may not be in the future. Melinda Shore I understand the intent I'm deeply uncomfortable with it, I understand when you see the must minus you should really thing about implementing the should+ but I think it leads to a less clear definition and it think it might tend to undermine interoperability becasue of it. because people are going to be less likely to implement musdt minuses if they think they're going to be removed in the future. Still what I think what you're trying to accomplish can be achieved with weasel word s in the text. this is a must implment with the understanding that it may be superseded in the future. trying to get several documents published recently is that they want algorithm agility in the cryptospecfications. Joel I think one of things I took away from the discussion on the list and my initial reading was that it required substantial changes in tone and language to, well there's a reason why they're looking to do it here rather than in rpsec. but alos that even in our evironment the way that this is setup is not going to fly and this disccusion is extremely valuable and needs to go into the document for it to go anywahere. Ron I tend to agree with melissa, this is alikely to get hung up in the IESG later on. joel I really like the word deprecated, you still have something you you have to implment because it's a must, but jeff haas For me a protocol specification says what you must do right now. projections as to what you might do in the future belongs in the non-normative text that surrounds it. Joel The issue for opsec on the question is the extent to which providing guidance to implementers is appropriate at all. When we come to this as an operator it's mostly a question of interoperability in the protocols I need to run my network. Chris Lonnvick Jeff Schiller's list of crytpo algorithms used the should- most+ (rfc 4307) language Joel Some level of referntiality might make this more clear. Gaurav Scheme for ospf crypto authentication is a must. Alogrithms selection is similar for isis, a more advanced algorithm should be implmentation Password authentication becomes a should not. Rich This is pretty much on target, I agree with the chair, that there are a number of little things we can comment on. I would suggest that the word authentication get up in the title because it just says cryptographic protection, becuase it only deals with authentication integrity. there are comments in some of these protocols about the need (or lack) of need for confidentiality that I reject out of hand because the need for it is a function of the operational enviroment not the implmentors view of the protocol. if you look in the ospf v3 spec it says hey, we recomend you do confidentiality because it's easy, whereas in these other specs it isn't so we don't. I reject that chain of logic. Joel I'll take back the mike, as we have 5 minutes. We got a second iteration of the draft kumari urpf document out it incorporates feedback from the list. original version didn't make it out in time for dublin so we didn't get commentary on it at the previous meeting. we are looking for consensus to accept it as a working group document. just to cruise through the changes associated with it. We have ietf tools we can get all the differences (the version number incremented) Text altered as a product of feedback no dramatic changes. Expansion of the practices documented in rfc 3882 It's pretty simple, as far as we can tell it reflects reality in terms of what operators do today with blackhole communities We think this is a good documentation exercise. we will ask from consensus to accept as a working group document and hopefuly last call it shortly thereafter. There's not really much to it. Appart from that. other documents that have been discussed or might be on the radar Michael bheringer's bgpsec requirements draft got discussed on the list a little bit, it was presented in Ireland. I think there is some opposition to taking on that work under our existing charter, I think his goals are sort of incompatible with this working group. if there are dramatic differences of opinion we can reconsider that . With warren we've been discussing the issue of a standardized blackhole community which would be a follow-on to the update to 3882. I asked peka about the backbone attacks draft presented in Dublin, the working group seemed receptive to at least hosting the document. From peka's perspective additional authoris to contribute to that doucment would be helpful but I din't think that a new iteration is immediately forthcoming. That's our current work in opsec. It may seem somewhat quiet on this lst but since the last meeting we've picked up two working group items and it looks like we should be asking for consensus on two more. that is kind of a full plate. we have something to show for our work. We're about done. Thanks! _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sat Dec 13 18:34:52 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F19D3A6829; Sat, 13 Dec 2008 18:34:52 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4733A6829 for ; Sat, 13 Dec 2008 18:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-+ePGc6MQbl for ; Sat, 13 Dec 2008 18:34:50 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 4E01A3A680E for ; Sat, 13 Dec 2008 18:34:50 -0800 (PST) Received: from [192.168.1.118] (c-24-130-16-195.hsd1.ca.comcast.net [24.130.16.195]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id mBE2Yejj009114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 14 Dec 2008 02:34:41 GMT (envelope-from joelja@bogus.com) Message-ID: <494470BF.3030901@bogus.com> Date: Sat, 13 Dec 2008 18:34:39 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: opsec wg mailing list X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV 0.93.3/8753/Sun Dec 14 00:26:44 2008 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] minutes part 3 (action items) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org These were the items I took away from or found in the previous two sections of the minutes please everyone, but especially Ruddinger Richard and Fernando please comment on anything I might have missed that we need to pose and answer on the list. deadline for submission of the minutes is the 19th so we have a couple days still. * draft-gont-opsec-ip-security-01 Test consensus on list for accepting as a working group document Preference for desired outcome, informational or BCP? Venues for cross area review, where should we socialize it Are there specifica areas that should get special attention? * draft-gont-opsec-icmp-filtering-00 Are we concluded that feedback on structure provided during the wg meeting was sufficient to proceed? Seperate v6 document or not * draft-ietf-opsec-routing-protocols-crypto-issues-00 Does this document need to address pim-sm or rsvp Other substantive comments? Is it ready for last call after another rev? * draft-bhatia-manral-igp-crypto-requirements-03 Accept as a working group document? Issue about language must- should+ etc (proposed change has circulated already) change of title (to include authentication) * draft-kumari-blackhole-urpf-02 Accept as a working group document? _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 16 08:32:20 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46FBD3A6A75; Tue, 16 Dec 2008 08:32:20 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0413A695B for ; Tue, 16 Dec 2008 08:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ggU-u2E8mUR for ; Tue, 16 Dec 2008 08:04:47 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 9278D3A67AC for ; Tue, 16 Dec 2008 08:04:47 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so746915qwe.31 for ; Tue, 16 Dec 2008 08:04:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:to:content-type :content-transfer-encoding:mime-version:subject:date:x-mailer:from; bh=BlrAkBxByuWUKer5JXbtsDUv1RXx0QNklqYwZ20XDhA=; b=tSWKDvQDTmAFQ2nwB7diNeHgvx048AkvNIP2giMCsrDBEdT1P/Ep5dGl31AJ8jAREl L108viWlpid3T9PddwGsqZ80J9Kmv6UPHwMjJKCk1D4oxqcnsk66+F8wljxUnE+SeoaT Yh3eLFdQxOEla5tksiTUietZTef5EVUk0+x9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:to:content-type:content-transfer-encoding:mime-version :subject:date:x-mailer:from; b=IFqzsoM8Mh3IcknQo4e9w9EZe6qNd6/pkbJu0V9ZBtA2f4UJz0GWAiBc5xahtHx5IE nJ2jsMj4J68H4uimws0HKlPw5rOlrFhBsTi0uyzBVJ5qcABXN8UccwDvxZ0qz2VQKkpp 1BSWz2sWet5WfekbvK7C0rpF+yiejc6ML0tnI= Received: by 10.214.60.5 with SMTP id i5mr9529074qaa.168.1229443478856; Tue, 16 Dec 2008 08:04:38 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 6sm14128401qwk.52.2008.12.16.08.04.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 08:04:38 -0800 (PST) Message-Id: To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 16 Dec 2008 11:04:31 -0500 X-Mailer: Apple Mail (2.930.3) From: RJ Atkinson X-Mailman-Approved-At: Tue, 16 Dec 2008 08:32:19 -0800 Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org All, This note is a response to parts of the above email. (I was presenting a paper at a research conference, so I was unable to attend IETF/MSP in person and make these comments then/there. I can't be in two cities at the same time. :-) First, let me observe that IGP attacks are all insider attacks. Sites routinely block IGP packets from entering from outside their administrative domain. (This would be a sensible thing for OPsec to recommend if it hasn't already done so.) Similarly, ISPs normally block IGP packets from arriving on customer-facing interfaces or other exterior interfaces. Second, prospective attackers are both smart and lazy. They are not likely to use a computationally expensive attack vector (e.g. something cryptographic) when a simpler/easier attack (e.g. DoS on the router CPU) exists. Third, I am not aware of any active attacks on any deployed IGP. I've worked at more than one network operator in the past, and for multiple equipment suppliers. I've never heard of even one. If active attacks were widespread or common, then they would have received much more reporting in the trade press (as different from the zero reports that I've seen over the past ~20 years). Fourth, the *only* goal of the various cryptographic IGP authentication mechanisms (excepting: RFC-2154) always has been to remove only the "passive attack" risks described long ago in RFC-1704. Such passive attacks are trivially easy to mount, even easier than a simple DOS attack, which is why they are sensible to protect against. Fifth, the existing cryptographic authentication mechanisms are not really widely deployed operationally. Many enterprise users don't enable any form of authentication. Some enable clear-text passwords; relatively few bother to enable cryptographic authentication. Among ISPs, security mechanisms are more widely deployed, but even in that community the existing cryptographic authentication mechanisms appear not to be widely used today. This is not because operators/users are silly or uninformed. Instead, this is because they are performing sensible risk/threat analyses and deploying what actually makes sense for their operational environments. % OSPF cryptographic sequence number spoofing or replay From a technical perspective, these are solved problems. Please see RFC-2154. Note that the absence of commercial implementations of RFC-2154 reflects the total absence of user/operator concern about either of these issues, along with user/operator concern about the complexity of a digital signature approach. % Need to move from md5 to stronger crypto. There is no obvious reason for a site to move from either Keyed-MD5 or HMAC-MD5 to something else. There are no known vulnerabilities in either Keyed-MD5 or HMAC-MD5 as used by IETF routing protocols. By contrast, moving to SHA will significantly increase a router's vulnerability to DOS attacks, while providing negligible decrease in risk. (Also see the comments 3 paragraphs down about SHA's own issues.) There is only one known user with any interest in SHA authentication for routing protocols. They have said that the only reason for that interest is "policy compliance". Even they have not yet indicated that SHA support is required of their equipment suppliers. Further, there are no known shipping implementations of SHA authentication for any IETF-specified IGP. (I don't know of any that are even "in progress".) Also, the concerns about collision attacks on MD5 (which are not known to affect either Keyed-MD5 or HMAC-MD5) are not fundamentally different from the concerns about collision attacks on SHA. 1. Several published academic papers about SHA issues are quite easily found by an online search: 2. NIST is working to replace SHA anyway (Nov 2007 announcement) So it seems silly to urge users to move to a security mode (e.g. SHA) that those users can't actually acquire or deploy, and whose underlying algorithm itself is likely to be deprecated in the near future by its own standards body (SHA is a NIST Federal Information Processing Standard). % Keys shared across the broadcast domain, % need to move to a stronger key identifier. 1. All IGPs multicast/broadcast their update packets, so sharing a key across that same multicast/broadcast domain is not a silly approach. 2. Adding a Key-ID does not actually increase the security of anything. It can make it slightly simpler for an implementation to locate the correct Security Association to use in attempting to authenticate a received packet, however the most widely deployed implementations *ignore* the Key-ID and instead just try all configured and valid SAs on the router. % For OSPFv3 relies on ipsec, because manual key sequence number, % replay protection cannot be used. See comment up top with reference to RFC-2154. % IS-IS MD5 but no sequence number not notion of keyid % for pdu key must be validated. See previous comments. Separately, IS-IS is carried directly over the link-layer, so off-link attacks are automatically precluded. This means that the only possible threat model is an on-link insider. There are simpler/easier attacks (e.g. DOS) on the routing infrastructure. So adding a sequence number doesn't really matter. Again, the KeyID is merely an implementer convenience, rather than some form of risk reduction. % Need to update from md5 There are no known attacks on either Keyed-MD5 or HMAC-MD5, so there is no obvious reason for a user/operator to deploy SHA authentication (or OSPF with Digital Signatures). Also recall that SHA itself has published issues. % ripv2, no authentication of ip or udp headers. can change % source address and receiver will still think it's a valid % neighbor If MD5 authentication is enabled, packets can't be forged. If one wants something stronger, a completely different "Digital Signature" approach (analagous to that described in RFC-2154 for OSPF) is the right direction to head (as the RIPv2 Authentication RFC already says). None of the recent documents in IGP authentication make any moves towards use of Digital Signatures, probably because there is no visible user/operator interest in this. % We need a distributed keyserver and the ospf guys need it % even more than we do. This is entirely believable, not because it increases security, but because it solves real-world operational/deployment issues. One logical approach to this would be to use a key distribution center (e.g. Kerberos). While Kerberos can be complex to deploy on all hosts in a large campus network, largely because of varying administrative domains, Kerberos is reportedly straight forward to deploy among all routers within a single administrative domain (although obviously it requires ordinary planning and care in deployment). At least one very large multi-continent ISP had deployed Kerberos over 10 years ago. Two widely deployed brands of router have already shipped Kerberos support, so this approach might be easier to get router implementers to support. Folks interested in this might want to put together a "requirements" draft as a first step. % gathering a group of people to identify the needs and go and % beat on msec Agreed. Using work from the IETF MSEC WG is another reasonable approach to adding key management for IGPs. % Second draft, minimum cryptographic requirements. the fact is % cryptographic algorithms continue to be attacked. we need to % keep track of this. the idea of this document is to keep % modifying it but to track the minimum requirements for interoperability I see this document as largely valueless. Most users/operators aren't enabling any form of cryptographic authentication today, because their risk/threat environment makes that not sensible for their operational domain. The market (i.e. users and RFPs) drive which IETF specifications are widely implemented by equipment suppliers. The days when IETF recommendations were widely and automatically obeyed by product managers at many equipment vendors has been gone for more than a decade now. I am not aware of *any* known attacks on any deployed IGP with any form of cryptographic authentication configured. If someone has actually seen such himself/herself, please provide the details here as that would be significant news. Again, there are no known vulnerabilities in either Keyed-MD5 or HMAC-MD5, and it is not obvious that SHA is necessarily either better or stronger (although it is measurably more computationally expensive for the router trying to authenticate a received packet). So there is no obvious security reason for an operational site to deploy something other than MD5. Heck, many sites don't even go that far today because their risk/threat model doesn't need it. In summary, the actual *operational* issue that this group can make an impact with would be to specify some requirements (from an operator/user perspective) for IGP authentication key management (so that IGP authentication is easier to configure/deploy/manage), and then work with other appropriate groups (e.g. Kerberos, MSEC) to have those groups add the necessary capabilities in their protocols. It seems to me that this would be a much better focus. If folks really think that the current approaches to IGP authentication aren't adequate, then they really ought to consider working on adding "Digital Signature" support for RIPv2 + IS-IS and they also ought to be asking their router suppliers to implement RFC-2154 support. Yours, Ran Atkinson rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 16 09:27:32 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8E028C0F5; Tue, 16 Dec 2008 09:27:32 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9651928C0F5 for ; Tue, 16 Dec 2008 09:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOiZmnuxvdkP for ; Tue, 16 Dec 2008 09:27:29 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 4A45B28C0DC for ; Tue, 16 Dec 2008 09:27:29 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so1514529fga.41 for ; Tue, 16 Dec 2008 09:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=hGECOXlvrjnvnNk4KP7G6KiKZYg+x/TBmIpafsI3OvU=; b=Ymf3kZRNY7WKkywASsPj+xqLzRw2Ycb+wjRAELbtgP7R/2eJx8D/OoYZRGBBZs6q0s VsknjYJLP4AtM0HwYv3M6iqsYIKwjudFz2+y2kxs9PZddpKCO4M9MeZg5WuyKdyaRfrJ DcRYvhBC7cHQfMcmp/8LIiQa20xtVqLRwaPsY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=qjAd1VJ0WelpybCG7aG5gIQ1h51UIMwN2uLgk+06TgoYMmj+wTIAiiA9hEvkVFPsiq UUO0U+sc7CpNAOm+LTbQRlyAT+c2oKzYhE3WnqKUY4qDxod8zHmSP2cQMsrP9tw4GbiQ 3p5AGtU3LHHi1accnrn7v/lu1hfYY2inmQLXQ= Received: by 10.86.50.6 with SMTP id x6mr4707370fgx.71.1229448440366; Tue, 16 Dec 2008 09:27:20 -0800 (PST) Received: by 10.86.70.17 with HTTP; Tue, 16 Dec 2008 09:27:19 -0800 (PST) Message-ID: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> Date: Tue, 16 Dec 2008 09:27:19 -0800 From: "Vishwas Manral" To: "RJ Atkinson" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, Thanks for the comments. You have mixed a lot of things in one mail, including current solutions, problems, future solutions, history, your opinions and a lot more. Let us try to discuss things one at a time and it will be helpful. I have taken the first major portion of the mail for now and to discuss the comments on the "Issues draft". On Tue, Dec 16, 2008 at 8:04 AM, RJ Atkinson wrote: > All, > > This note is a response to parts of the above email. > (I was presenting a paper at a research conference, > so I was unable to attend IETF/MSP in person and > make these comments then/there. I can't be in > two cities at the same time. :-) Thanks for the detailed mail. I hope this can compensate for you not being able to attend the meeting. :) > First, let me observe that IGP attacks are all insider attacks. > Sites routinely block IGP packets from entering from outside > their administrative domain. (This would be a sensible thing > for OPsec to recommend if it hasn't already done so.) > Similarly, ISPs normally block IGP packets from arriving > on customer-facing interfaces or other exterior interfaces. Thanks for the information about insider attacks. I have raised issues with using IPsec ESP for OSPFv3 protection about 3 years back, as we cannot block packets in all such cases (as the firewall may not know of the contents inside the ESP packet). Although this is a "routine" like you said we can add it is a solutions document. However the document is about issues and not solutions. > Second, prospective attackers are both smart and lazy. They > are not likely to use a computationally expensive attack > vector (e.g. something cryptographic) when a simpler/easier > attack (e.g. DoS on the router CPU) exists. Agree its always the weakest link that anyone would want to exploit, not the strongest one. However if you see most drafts "security considerations" section, they state that using cryptographic authentication is a panicia for all evils. Our aim is to bring out issues even when cryptographic authentication is available. > Third, I am not aware of any active attacks on any deployed > IGP. I've worked at more than one network operator in the > past, and for multiple equipment suppliers. I've never heard > of even one. If active attacks were widespread or common, > then they would have received much more reporting in the > trade press (as different from the zero reports that I've > seen over the past ~20 years). This seems to contradict what you stated as the first point about "First, let me observe that IGP attacks are all insider attacks." Well we do not have to wait for the first attack to act, we need to react even before the attacks occur. You may have noted a similar move in all Security groups even though attacks themselves have not occured yet. Also note we have to consider the havoc to the forwarded traffic that can be caused if the routing infrastructure is compromised. So the effect of an attack is more than just attacking an end user site. > Fourth, the *only* goal of the various cryptographic IGP > authentication mechanisms (excepting: RFC-2154) always > has been to remove only the "passive attack" risks described > long ago in RFC-1704. Such passive attacks are trivially > easy to mount, even easier than a simple DOS attack, which > is why they are sensible to protect against. Agree partially. It is a goal but not the only goal of cryptographic mechanisms. > Fifth, the existing cryptographic authentication mechanisms > are not really widely deployed operationally. Many enterprise > users don't enable any form of authentication. Some enable > clear-text passwords; relatively few bother to enable > cryptographic authentication. Among ISPs, security mechanisms > are more widely deployed, but even in that community the > existing cryptographic authentication mechanisms appear not > to be widely used today. This is not because operators/users > are silly or uninformed. Instead, this is because they are > performing sensible risk/threat analyses and deploying what > actually makes sense for their operational environments. Comments given above. > % OSPF cryptographic sequence number spoofing or replay > > From a technical perspective, these are solved problems. > Please see RFC-2154. Note that the absence of commercial > implementations of RFC-2154 reflects the total absence > of user/operator concern about either of these issues, > along with user/operator concern about the complexity > of a digital signature approach. IPsec with Manual Keying still states there can be no Replay protection. > % Need to move from md5 to stronger crypto. > There is no obvious reason for a site to move from either > Keyed-MD5 or HMAC-MD5 to something else. There are no known > vulnerabilities in either Keyed-MD5 or HMAC-MD5 as used by > IETF routing protocols. By contrast, moving to SHA will > significantly increase a router's vulnerability to DOS attacks, > while providing negligible decrease in risk. (Also see > the comments 3 paragraphs down about SHA's own issues.) > There is only one known user with any interest in SHA > authentication for routing protocols. They have said > that the only reason for that interest is "policy compliance". > Even they have not yet indicated that SHA support is required > of their equipment suppliers. The only known user interest to your knowledge. As noted by the Routing AD's, IETF manadates we move out of support for MD5 and into supporting other algorithms as stated. > Further, there are no known shipping implementations of > SHA authentication for any IETF-specified IGP. (I don't > know of any that are even "in progress".) We know of a few including a big router vendor. :)) > Also, the concerns about collision attacks on MD5 (which > are not known to affect either Keyed-MD5 or HMAC-MD5) > are not fundamentally different from the concerns about > collision attacks on SHA. Agree. > 1. Several published academic papers about SHA issues > are quite easily found by an online search: > > > 2. NIST is working to replace SHA anyway (Nov 2007 announcement) > > > So it seems silly to urge users to move to a security mode > (e.g. SHA) that those users can't actually acquire or deploy, > and whose underlying algorithm itself is likely to be deprecated > in the near future by its own standards body (SHA is a NIST Federal > Information Processing Standard). The urge is to get into HMAC-SHA1 not SHA1. I will cover the rest in another mail some day later. Thanks, Vishwas > % Keys shared across the broadcast domain, > % need to move to a stronger key identifier. > > 1. All IGPs multicast/broadcast their update packets, > so sharing a key across that same multicast/broadcast > domain is not a silly approach. > > 2. Adding a Key-ID does not actually increase the > security of anything. It can make it slightly simpler > for an implementation to locate the correct Security > Association to use in attempting to authenticate a > received packet, however the most widely deployed > implementations *ignore* the Key-ID and instead just > try all configured and valid SAs on the router. > > % For OSPFv3 relies on ipsec, because manual key sequence number, > % replay protection cannot be used. > > See comment up top with reference to RFC-2154. > > % IS-IS MD5 but no sequence number not notion of keyid > % for pdu key must be validated. > > See previous comments. > > Separately, IS-IS is carried directly over the link-layer, > so off-link attacks are automatically precluded. This means > that the only possible threat model is an on-link insider. > There are simpler/easier attacks (e.g. DOS) on the routing > infrastructure. So adding a sequence number doesn't really matter. > Again, the KeyID is merely an implementer convenience, rather than > some form of risk reduction. > > % Need to update from md5 > > There are no known attacks on either Keyed-MD5 or HMAC-MD5, > so there is no obvious reason for a user/operator to deploy > SHA authentication (or OSPF with Digital Signatures). Also > recall that SHA itself has published issues. > > % ripv2, no authentication of ip or udp headers. can change > % source address and receiver will still think it's a valid > % neighbor > > If MD5 authentication is enabled, packets can't be forged. > > If one wants something stronger, a completely different > "Digital Signature" approach (analagous to that described > in RFC-2154 for OSPF) is the right direction to head (as > the RIPv2 Authentication RFC already says). > > None of the recent documents in IGP authentication make any moves > towards use of Digital Signatures, probably because there is no > visible user/operator interest in this. > > % We need a distributed keyserver and the ospf guys need it > % even more than we do. > > This is entirely believable, not because it increases security, > but because it solves real-world operational/deployment issues. > > One logical approach to this would be to use a key distribution > center (e.g. Kerberos). While Kerberos can be complex to deploy > on all hosts in a large campus network, largely because of varying > administrative domains, Kerberos is reportedly straight forward > to deploy among all routers within a single administrative domain > (although obviously it requires ordinary planning and care in > deployment). > > At least one very large multi-continent ISP had deployed Kerberos > over 10 years ago. Two widely deployed brands of router have > already shipped Kerberos support, so this approach might be > easier to get router implementers to support. Folks interested > in this might want to put together a "requirements" draft as a first step. > > % gathering a group of people to identify the needs and go and > % beat on msec > > Agreed. Using work from the IETF MSEC WG is another reasonable > approach to adding key management for IGPs. > > % Second draft, minimum cryptographic requirements. the fact is > % cryptographic algorithms continue to be attacked. we need to > % keep track of this. the idea of this document is to keep > % modifying it but to track the minimum requirements for interoperability > > I see this document as largely valueless. Most users/operators > aren't enabling any form of cryptographic authentication today, > because their risk/threat environment makes that not sensible > for their operational domain. > > The market (i.e. users and RFPs) drive which IETF specifications > are widely implemented by equipment suppliers. The days when > IETF recommendations were widely and automatically obeyed by > product managers at many equipment vendors has been gone > for more than a decade now. > > I am not aware of *any* known attacks on any deployed IGP with > any form of cryptographic authentication configured. If someone > has actually seen such himself/herself, please provide the details > here as that would be significant news. > > Again, there are no known vulnerabilities in either Keyed-MD5 or > HMAC-MD5, and it is not obvious that SHA is necessarily either > better or stronger (although it is measurably more computationally > expensive for the router trying to authenticate a received packet). > So there is no obvious security reason for an operational > site to deploy something other than MD5. Heck, many sites don't even > go that far today because their risk/threat model doesn't need it. > > In summary, the actual *operational* issue that this group can > make an impact with would be to specify some requirements (from > an operator/user perspective) for IGP authentication key management > (so that IGP authentication is easier to configure/deploy/manage), > and then work with other appropriate groups (e.g. Kerberos, MSEC) > to have those groups add the necessary capabilities in their > protocols. It seems to me that this would be a much better focus. > > If folks really think that the current approaches to IGP authentication > aren't adequate, then they really ought to consider working on adding > "Digital Signature" support for RIPv2 + IS-IS and they also ought > to be asking their router suppliers to implement RFC-2154 support. > > Yours, > > Ran Atkinson > rja@extremenetworks.com > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 16 10:42:34 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272563A6A86; Tue, 16 Dec 2008 10:42:34 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC4243A6A86 for ; Tue, 16 Dec 2008 10:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7vrzVujhS7n for ; Tue, 16 Dec 2008 10:40:17 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id E6A503A6A8B for ; Tue, 16 Dec 2008 10:40:16 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so1351136ywj.49 for ; Tue, 16 Dec 2008 10:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=ZLZ8VHNfKHpmQjYW8IVWKi9O3XlUtB1tfzbLWKU1NdQ=; b=Pdt/mq1JVnhKLTiHgkEoIzUUAuhEAYN8EHmfY98bR5e9zbWLtHnk1vaM3m8A8L2NHG ByRMfgrr7t6FXAME7SPHNq5T2URxEfO9utU7tiGxmcW8XCY+OeJE82RYRSdKRDI0RWk+ Tq5K6puDL4GcUhr1Xe1R+WlDCOrp2TNY0Gh98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=GBm19OBvc7Eheehs9qi/1KYLSxU35EfGq12/y1Mkbf5LH/QDqJDLU+4+z7sxT5Q+UV MnPmfKVQCbrkzBhCa6R5Q87SeANhh3vdT0+YsbnSw9aFtDWIiDQ89wQuj6Pz4Pem+HbE xR+e8EAnh35l1bEj5Fdvv+EYOJLRSfeXpJpAo= Received: by 10.65.177.6 with SMTP id e6mr4109457qbp.97.1229452808375; Tue, 16 Dec 2008 10:40:08 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id k8sm3546666qba.5.2008.12.16.10.40.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 10:40:07 -0800 (PST) Message-Id: <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 16 Dec 2008 13:40:05 -0500 References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Tue, 16 Dec 2008 10:42:32 -0800 Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org (NB: All of my references to "SHA" include "SHA1 and "SHA2" also.) On 16 Dec 2008, at 12:27, Vishwas Manral wrote: > Thanks for the information about insider attacks. I have raised issues > with using IPsec ESP for OSPFv3 protection about 3 years back, as we > cannot block packets in all such cases (as the firewall may not know > of the contents inside the ESP packet). Your claim above is not obvious. Please explain when/why you believe the claim above is true. >> Second, prospective attackers are both smart and lazy. They >> are not likely to use a computationally expensive attack >> vector (e.g. something cryptographic) when a simpler/easier >> attack (e.g. DoS on the router CPU) exists. > Agree its always the weakest link that anyone would want to exploit, > not the strongest one. However if you see most drafts "security > considerations" section, they state that using cryptographic > authentication is a panicia for all evils. That is NOT true for any of the IGP authentication RFCs or I-Ds. In fact, the IGP authentication RFCs tend to be unusually clear about the limitations of those mechanisms. > Our aim is to bring out issues even when cryptographic > authentication is available. The limitations are generally already documented in the IGP authentication documents' "Security Considerations" sections. >> Third, I am not aware of any active attacks on any deployed >> IGP. I've worked at more than one network operator in the >> past, and for multiple equipment suppliers. I've never heard >> of even one. If active attacks were widespread or common, >> then they would have received much more reporting in the >> trade press (as different from the zero reports that I've >> seen over the past ~20 years). > > This seems to contradict what you stated as the first point about > "First, let me observe that IGP attacks are all insider attacks." Not at all. This looks like an English language issue to me: - All IGP attacks would have to be insider attacks, because external packets are normally filtered anyway. - I am not aware of any IGP attacks ever occurring in the deployed world. There might be some, but I am not aware of any published reports during the past ~20 years. - If someone has seen an actual active attack on any IGP, that would be VERY interesting to learn more about. > Well we do not have to wait for the first attack to act, we need to > react even before the attacks occur. You may have noted a similar move > in all Security groups even though attacks themselves have not occured > yet. Network operators have a range of mechanisms available now in shipping routers. Which mechanisms, if any, make sense to deploy is entirely up to their judgement -- based on their risk/threat model for their specific deployment. > Also note we have to consider the havoc to the forwarded traffic that > can be caused if the routing infrastructure is compromised. So the > effect of an attack is more than just attacking an end user site. Again, there are a range of existing mechanisms that network operators can choose to use -- and there seem to be no reports of any IGP attack in the real world. >> Fourth, the *only* goal of the various cryptographic IGP >> authentication mechanisms (excepting: RFC-2154) always >> has been to remove only the "passive attack" risks described >> long ago in RFC-1704. Such passive attacks are trivially >> easy to mount, even easier than a simple DOS attack, which >> is why they are sensible to protect against. > Agree partially. It is a goal but not the only goal of cryptographic > mechanisms. You personally might have different goals for IGP authentication, but the various mechanisms extant (excepting RFC-2154) were only designed to protect against passive attacks (as described in RFC-1704). I have either authored or co-authored every one of those IGP mechanisms (e.g. the OSPF MD5 mechanism is why I get the acknowledgement in the OSPF RFCs). They protect against a limited set of issues. The limitations are widely understood in the community. For example, at the BOF held at IETF/Dublin, the entire room appeared to understood from the beginning that the current mechanisms are very limited. I was quite clear in my comments during that BOF that the current mechanisms are limited. If one wants more, then the work that other folks have done with "Digital Signatures" (RFC-2154) seems like the right direction to go. That approach provides MUCH more comprehensive protections than any other current mechanisms. (This is all a rehash of comments I made during the KMART BOF at IETF/PHL, not all of which comments made it into the minutes.) IS-IS and RIP likely would benefit from having equivalent specifications developed; for OSPF, RFC-2154 already exists. (I have no personal interest in developing such "Digital Signature" specifications for either IS-IS or RIP, but perhaps other folks here do. I think it would be helpful to have the specifications completed and openly specified so that users who wanted something stronger could ask for something specific.) >> Fifth, the existing cryptographic authentication mechanisms >> are not really widely deployed operationally. Many enterprise >> users don't enable any form of authentication. Some enable >> clear-text passwords; relatively few bother to enable >> cryptographic authentication. Among ISPs, security mechanisms >> are more widely deployed, but even in that community the >> existing cryptographic authentication mechanisms appear not >> to be widely used today. This is not because operators/users >> are silly or uninformed. Instead, this is because they are >> performing sensible risk/threat analyses and deploying what >> actually makes sense for their operational environments. > Comments given above. None of which comments above address the text which you have quoted. >> % OSPF cryptographic sequence number spoofing or replay >> >> From a technical perspective, these are solved problems. >> Please see RFC-2154. Note that the absence of commercial >> implementations of RFC-2154 reflects the total absence >> of user/operator concern about either of these issues, >> along with user/operator concern about the complexity >> of a digital signature approach. > IPsec with Manual Keying still states there can be no Replay > protection. RFC-2154 does not use IPsec. So a comment about IPsec is orthogonal to the discussion. Please go read RFC-2154. >> There is only one known user with any interest in SHA >> authentication for routing protocols. They have said >> that the only reason for that interest is "policy compliance". >> Even they have not yet indicated that SHA support is required >> of their equipment suppliers. > The only known user interest to your knowledge. Yes, of course -- to my own knowledge. Do you know of anyone other than US DoD that wants this ? (US DoD are the only ones that I can identify, and they are saying their interest is only for "policy reasons".) If so, which users ? which RFPs ? For that matter, are there any users/operators on this list that have concrete plans to move to SHA for IGP authentication anytime soon ? > As noted by the Routing AD's, IETF manadates we move out of support > for MD5 and into supporting other algorithms as stated. Yes, the requirement is for algorithm agility, which we already had with the older Keyed-MD5 mechanisms. The mechanisms themselves were algorithm-independent, although only one algorithm happened to be specified at the time (due to limited user interest). Algorithm agility is a fine thing, as I noted in a paper written for IEEE Network [1], but it is different from urging folks to change their deployed algorithms. I had suggested that changing the deployed algorithm from MD5 to SHA seemed unwarranted. You haven't addressed that comment. >> Further, there are no known shipping implementations of >> SHA authentication for any IETF-specified IGP. >> (I don't know of any that are even "in progress".) > We know of a few including a big router vendor. :)) Please do name all of the names. :-) I think it would be helpful for everyone to know which implementations have already shipped and which might be coming soon. >> Also, the concerns about collision attacks on MD5 (which >> are not known to affect either Keyed-MD5 or HMAC-MD5) >> are not fundamentally different from the concerns about >> collision attacks on SHA. > Agree. Given that you agree the concerns are the same, then why does your draft push SHA over MD5 ? >> 1. Several published academic papers about SHA issues >> are quite easily found by an online search: >> > +attack&hl=en&lr=&btnG=Search> >> >> 2. NIST is working to replace SHA anyway (Nov 2007 announcement) >> > > >> >> So it seems silly to urge users to move to a security mode >> (e.g. SHA) that those users can't actually acquire or deploy, >> and whose underlying algorithm itself is likely to be deprecated >> in the near future by its own standards body (SHA is a NIST Federal >> Information Processing Standard). > > The urge is to get into HMAC-SHA1 not SHA1. Moving to HMAC-SHA1 does NOT necessarily improve security over current algorithms. Moving to HMAC-SHA1 does mean that the CPU on a router receiving a DOS attack via some IGP would be more severely impacted (because SHA1 is more computationally expensive than MD5).[2] In fact, there are no known attacks (so far) upon any of these: - Keyed MD5 - HMAC MD5 - HMAC SHA/SHA1/SHA2 [If someone knows of a published attack on any of the above, please do post a full bibliographic citation here, so that WG participants can go find/read the paper in question. If some new discovery has happened, I'm personally quite keen to learn about it. :-] So I've shown in my earlier note that there are equivalent concerns with aspects of both cryptographic hash functions specified by the IETF: - MD5 - SHA/SHA1/SHA2 And we know from the URL I provided earlier that NIST is actively moving to deprecate all use of SHA/SHA1, including HMAC-SHA1. So one can see that there is no obvious net gain for users moving to HMAC-SHA for IGP authentication, relative to either HMAC-MD5 or Keyed-MD5. Moreover, there is increased impact on the router CPU (and hence the router control plane generally) of a prospective DOS attack on IGP packets if any form of SHA is used.[2] And to repeat another central point: - Key management for IGP authentication really could benefit from some IETF standards work. It would make any of this MUCH easier to configure and deploy. MSEC and Kerberos are among possible approaches to IGP key management. For this group, the role might be to draft an "IGP KM Requirements" document for the other WGs to work from. Yours, Ran rja@extremenetworks.com [1] R. Atkinson, "Toward a More Secure Internet", IEEE Computer, Vol. 30, Number 1, January 1997. [2] One example DOS attack was presented in an IETF WG session by someone else some years back (1990s). Basically, the adversary creates a packet that is syntatically valid to the IGP specification, then puts arbitrary bits into the Authentication Data field of the packet, and sends it to a router. The receiving router receives the packet and the router CPU then performs expensive cryptographic computations that are all wasted CPU cycles (because the bits in that field were arbitrary) before tossing the DOS IGP packet. Other DOS attacks exist, of course, this is just an example. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 16 10:49:56 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 905273A6A9B; Tue, 16 Dec 2008 10:49:56 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1AFD3A6840 for ; Tue, 16 Dec 2008 10:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgTGxgB+XotQ for ; Tue, 16 Dec 2008 10:49:53 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 23EF73A6A8A for ; Tue, 16 Dec 2008 10:49:53 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so761596qwe.31 for ; Tue, 16 Dec 2008 10:49:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:resent-to:from:to:in-reply-to :resent-from:subject:references:message-id:content-type :content-transfer-encoding:resent-date:mime-version:date:x-mailer; bh=ZLZ8VHNfKHpmQjYW8IVWKi9O3XlUtB1tfzbLWKU1NdQ=; b=FrFgXNWO8yiH8EccefiKO6M865WmOhHmShEXw/ORPkVIjtLLtYKd4o+f1JRw4cJwvp jv9L5WGJIkRC0JXtFN7NWp1oGKWJ0HC+Ogftz3/397w5llXzIrYEwzKkvukXz3PIMi4E R/FKghj3T1W0CSj24N2Z27xP7kOAs5oJc1/rE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=resent-to:from:to:in-reply-to:resent-from:subject:references :message-id:content-type:content-transfer-encoding:resent-date :mime-version:date:x-mailer; b=ID9rz8fR1IXXuB+hLhlJtkSwnQ8hBUEkgy2Ly6sJAq8OEu3Hir8v+TQldkQOz4fUtI n+F4K0QgJrHrbSelJcrE4UmW4bsawDzR6ez8rCD047t4zatIGSi4hmnWU9hRL8rLrq3d XTYMzyyyC+r0h9AG0Rp1iIUo2tpUjyOmyBkhk= Received: by 10.215.12.3 with SMTP id p3mr9836792qai.39.1229453384486; Tue, 16 Dec 2008 10:49:44 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 9sm973096yws.18.2008.12.16.10.49.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 10:49:44 -0800 (PST) Resent-To: opsec@ietf.org From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> Resent-From: R Atkinson References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> Message-Id: <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> Resent-Date: Tue, 16 Dec 2008 13:49:27 -0500 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 16 Dec 2008 13:40:05 -0500 X-Mailer: Apple Mail (2.930.3) Resent-Message-Id: <20081216184953.23EF73A6A8A@core3.amsl.com> Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org (NB: All of my references to "SHA" include "SHA1 and "SHA2" also.) On 16 Dec 2008, at 12:27, Vishwas Manral wrote: > Thanks for the information about insider attacks. I have raised issues > with using IPsec ESP for OSPFv3 protection about 3 years back, as we > cannot block packets in all such cases (as the firewall may not know > of the contents inside the ESP packet). Your claim above is not obvious. Please explain when/why you believe the claim above is true. >> Second, prospective attackers are both smart and lazy. They >> are not likely to use a computationally expensive attack >> vector (e.g. something cryptographic) when a simpler/easier >> attack (e.g. DoS on the router CPU) exists. > Agree its always the weakest link that anyone would want to exploit, > not the strongest one. However if you see most drafts "security > considerations" section, they state that using cryptographic > authentication is a panicia for all evils. That is NOT true for any of the IGP authentication RFCs or I-Ds. In fact, the IGP authentication RFCs tend to be unusually clear about the limitations of those mechanisms. > Our aim is to bring out issues even when cryptographic > authentication is available. The limitations are generally already documented in the IGP authentication documents' "Security Considerations" sections. >> Third, I am not aware of any active attacks on any deployed >> IGP. I've worked at more than one network operator in the >> past, and for multiple equipment suppliers. I've never heard >> of even one. If active attacks were widespread or common, >> then they would have received much more reporting in the >> trade press (as different from the zero reports that I've >> seen over the past ~20 years). > > This seems to contradict what you stated as the first point about > "First, let me observe that IGP attacks are all insider attacks." Not at all. This looks like an English language issue to me: - All IGP attacks would have to be insider attacks, because external packets are normally filtered anyway. - I am not aware of any IGP attacks ever occurring in the deployed world. There might be some, but I am not aware of any published reports during the past ~20 years. - If someone has seen an actual active attack on any IGP, that would be VERY interesting to learn more about. > Well we do not have to wait for the first attack to act, we need to > react even before the attacks occur. You may have noted a similar move > in all Security groups even though attacks themselves have not occured > yet. Network operators have a range of mechanisms available now in shipping routers. Which mechanisms, if any, make sense to deploy is entirely up to their judgement -- based on their risk/threat model for their specific deployment. > Also note we have to consider the havoc to the forwarded traffic that > can be caused if the routing infrastructure is compromised. So the > effect of an attack is more than just attacking an end user site. Again, there are a range of existing mechanisms that network operators can choose to use -- and there seem to be no reports of any IGP attack in the real world. >> Fourth, the *only* goal of the various cryptographic IGP >> authentication mechanisms (excepting: RFC-2154) always >> has been to remove only the "passive attack" risks described >> long ago in RFC-1704. Such passive attacks are trivially >> easy to mount, even easier than a simple DOS attack, which >> is why they are sensible to protect against. > Agree partially. It is a goal but not the only goal of cryptographic > mechanisms. You personally might have different goals for IGP authentication, but the various mechanisms extant (excepting RFC-2154) were only designed to protect against passive attacks (as described in RFC-1704). I have either authored or co-authored every one of those IGP mechanisms (e.g. the OSPF MD5 mechanism is why I get the acknowledgement in the OSPF RFCs). They protect against a limited set of issues. The limitations are widely understood in the community. For example, at the BOF held at IETF/Dublin, the entire room appeared to understood from the beginning that the current mechanisms are very limited. I was quite clear in my comments during that BOF that the current mechanisms are limited. If one wants more, then the work that other folks have done with "Digital Signatures" (RFC-2154) seems like the right direction to go. That approach provides MUCH more comprehensive protections than any other current mechanisms. (This is all a rehash of comments I made during the KMART BOF at IETF/PHL, not all of which comments made it into the minutes.) IS-IS and RIP likely would benefit from having equivalent specifications developed; for OSPF, RFC-2154 already exists. (I have no personal interest in developing such "Digital Signature" specifications for either IS-IS or RIP, but perhaps other folks here do. I think it would be helpful to have the specifications completed and openly specified so that users who wanted something stronger could ask for something specific.) >> Fifth, the existing cryptographic authentication mechanisms >> are not really widely deployed operationally. Many enterprise >> users don't enable any form of authentication. Some enable >> clear-text passwords; relatively few bother to enable >> cryptographic authentication. Among ISPs, security mechanisms >> are more widely deployed, but even in that community the >> existing cryptographic authentication mechanisms appear not >> to be widely used today. This is not because operators/users >> are silly or uninformed. Instead, this is because they are >> performing sensible risk/threat analyses and deploying what >> actually makes sense for their operational environments. > Comments given above. None of which comments above address the text which you have quoted. >> % OSPF cryptographic sequence number spoofing or replay >> >> From a technical perspective, these are solved problems. >> Please see RFC-2154. Note that the absence of commercial >> implementations of RFC-2154 reflects the total absence >> of user/operator concern about either of these issues, >> along with user/operator concern about the complexity >> of a digital signature approach. > IPsec with Manual Keying still states there can be no Replay > protection. RFC-2154 does not use IPsec. So a comment about IPsec is orthogonal to the discussion. Please go read RFC-2154. >> There is only one known user with any interest in SHA >> authentication for routing protocols. They have said >> that the only reason for that interest is "policy compliance". >> Even they have not yet indicated that SHA support is required >> of their equipment suppliers. > The only known user interest to your knowledge. Yes, of course -- to my own knowledge. Do you know of anyone other than US DoD that wants this ? (US DoD are the only ones that I can identify, and they are saying their interest is only for "policy reasons".) If so, which users ? which RFPs ? For that matter, are there any users/operators on this list that have concrete plans to move to SHA for IGP authentication anytime soon ? > As noted by the Routing AD's, IETF manadates we move out of support > for MD5 and into supporting other algorithms as stated. Yes, the requirement is for algorithm agility, which we already had with the older Keyed-MD5 mechanisms. The mechanisms themselves were algorithm-independent, although only one algorithm happened to be specified at the time (due to limited user interest). Algorithm agility is a fine thing, as I noted in a paper written for IEEE Network [1], but it is different from urging folks to change their deployed algorithms. I had suggested that changing the deployed algorithm from MD5 to SHA seemed unwarranted. You haven't addressed that comment. >> Further, there are no known shipping implementations of >> SHA authentication for any IETF-specified IGP. >> (I don't know of any that are even "in progress".) > We know of a few including a big router vendor. :)) Please do name all of the names. :-) I think it would be helpful for everyone to know which implementations have already shipped and which might be coming soon. >> Also, the concerns about collision attacks on MD5 (which >> are not known to affect either Keyed-MD5 or HMAC-MD5) >> are not fundamentally different from the concerns about >> collision attacks on SHA. > Agree. Given that you agree the concerns are the same, then why does your draft push SHA over MD5 ? >> 1. Several published academic papers about SHA issues >> are quite easily found by an online search: >> > +attack&hl=en&lr=&btnG=Search> >> >> 2. NIST is working to replace SHA anyway (Nov 2007 announcement) >> > > >> >> So it seems silly to urge users to move to a security mode >> (e.g. SHA) that those users can't actually acquire or deploy, >> and whose underlying algorithm itself is likely to be deprecated >> in the near future by its own standards body (SHA is a NIST Federal >> Information Processing Standard). > > The urge is to get into HMAC-SHA1 not SHA1. Moving to HMAC-SHA1 does NOT necessarily improve security over current algorithms. Moving to HMAC-SHA1 does mean that the CPU on a router receiving a DOS attack via some IGP would be more severely impacted (because SHA1 is more computationally expensive than MD5).[2] In fact, there are no known attacks (so far) upon any of these: - Keyed MD5 - HMAC MD5 - HMAC SHA/SHA1/SHA2 [If someone knows of a published attack on any of the above, please do post a full bibliographic citation here, so that WG participants can go find/read the paper in question. If some new discovery has happened, I'm personally quite keen to learn about it. :-] So I've shown in my earlier note that there are equivalent concerns with aspects of both cryptographic hash functions specified by the IETF: - MD5 - SHA/SHA1/SHA2 And we know from the URL I provided earlier that NIST is actively moving to deprecate all use of SHA/SHA1, including HMAC-SHA1. So one can see that there is no obvious net gain for users moving to HMAC-SHA for IGP authentication, relative to either HMAC-MD5 or Keyed-MD5. Moreover, there is increased impact on the router CPU (and hence the router control plane generally) of a prospective DOS attack on IGP packets if any form of SHA is used.[2] And to repeat another central point: - Key management for IGP authentication really could benefit from some IETF standards work. It would make any of this MUCH easier to configure and deploy. MSEC and Kerberos are among possible approaches to IGP key management. For this group, the role might be to draft an "IGP KM Requirements" document for the other WGs to work from. Yours, Ran rja@extremenetworks.com [1] R. Atkinson, "Toward a More Secure Internet", IEEE Computer, Vol. 30, Number 1, January 1997. [2] One example DOS attack was presented in an IETF WG session by someone else some years back (1990s). Basically, the adversary creates a packet that is syntatically valid to the IGP specification, then puts arbitrary bits into the Authentication Data field of the packet, and sends it to a router. The receiving router receives the packet and the router CPU then performs expensive cryptographic computations that are all wasted CPU cycles (because the bits in that field were arbitrary) before tossing the DOS IGP packet. Other DOS attacks exist, of course, this is just an example. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 16 11:18:50 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C81513A6800; Tue, 16 Dec 2008 11:18:50 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24C2E3A6800 for ; Tue, 16 Dec 2008 11:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4El3biOdc+l for ; Tue, 16 Dec 2008 11:18:48 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 979223A67F1 for ; Tue, 16 Dec 2008 11:18:47 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so1536070fga.41 for ; Tue, 16 Dec 2008 11:18:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=6SFEWEuko9Qac8uUxnbcrVDEbgZiAZ2yyYwYdUinKTc=; b=Q7RYjY35ZisbMNDjF6L90Fu4Uo8dbWXPVc3ZqvAF1Odn1AnUfskmk2YLrpnqvrFuy9 ZqDKpdPqtqXfUX3EDprkhf5dZmPMH/sPkDQA5xeV6cRemVSYrkggxgTWqfEz3Muy8SSb UgzCw7v0uqHqjKP3yZ3HrWA3WsQeJIZNfR0XI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Qu6l6i7DtAJytx075qgzdtibKCO4t/BoSvNdNxvS1esGOJsv9xQSmGBPhmny4vRQ9V vbgj8B/UdAs4kYNpOcjA0lxznm5z8nle7XnIE3rTFqayLlVK28htHpEr3Eenbq1PT4Tp IaMLnDApv/oYiCMEOcsQIs/Y8I92SClgGmVvM= Received: by 10.86.59.18 with SMTP id h18mr4735599fga.75.1229455118841; Tue, 16 Dec 2008 11:18:38 -0800 (PST) Received: by 10.86.70.17 with HTTP; Tue, 16 Dec 2008 11:18:38 -0800 (PST) Message-ID: <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> Date: Tue, 16 Dec 2008 11:18:38 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> Cc: opsec wg mailing list Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, Thanks again for the thoughtful comments. Most of the comments are about solutions to get the problems solved. Let me again state that this document lists issues with existing cryptographic mechanisms. It is not a solutions document, if we have solutions like Digital Signatures we can have the mechanisms. If you do not agree to the solutions drafts of which you are a co-author (and the work is in other working groups), we can see what can be done. > (NB: All of my references to "SHA" include "SHA1 and "SHA2" also.) > > On 16 Dec 2008, at 12:27, Vishwas Manral wrote: >> >> Thanks for the information about insider attacks. I have raised issues >> with using IPsec ESP for OSPFv3 protection about 3 years back, as we >> cannot block packets in all such cases (as the firewall may not know >> of the contents inside the ESP packet). > > Your claim above is not obvious. > Please explain when/why you believe the claim above is true. Please see the discussion on the IPsec Maintainance working group. Check the topic "Deep Inspecting ESP-NULL Packets" and the related draft solutions currently being proposed. However this is not in the scope of this document or discussion. If you have issues with this let us discuss the same in the right forum. >>> Second, prospective attackers are both smart and lazy. They >>> are not likely to use a computationally expensive attack >>> vector (e.g. something cryptographic) when a simpler/easier >>> attack (e.g. DoS on the router CPU) exists. >> >> Agree its always the weakest link that anyone would want to exploit, >> not the strongest one. However if you see most drafts "security >> considerations" section, they state that using cryptographic >> authentication is a panicia for all evils. > > That is NOT true for any of the IGP authentication RFCs or I-Ds. > In fact, the IGP authentication RFCs tend to be unusually clear > about the limitations of those mechanisms. I opened the base OSPF RFC Page 242 please note that they talk about only security when athentication is enabled. They do not delve into issues that might occur with the security mechanisms themselves into picture. >> Our aim is to bring out issues even when cryptographic >> authentication is available. > > The limitations are generally already documented in the IGP > authentication documents' "Security Considerations" sections. No it isnt. Can you please map the RFC2328 security section with the OSPF vulnerabilities mentioned. Please do the same exercise for BFD, or for other protocols. It will be clear what we are talking about. >>> Third, I am not aware of any active attacks on any deployed >>> IGP. I've worked at more than one network operator in the >>> past, and for multiple equipment suppliers. I've never heard >>> of even one. If active attacks were widespread or common, >>> then they would have received much more reporting in the >>> trade press (as different from the zero reports that I've >>> seen over the past ~20 years). >> >> This seems to contradict what you stated as the first point about >> "First, let me observe that IGP attacks are all insider attacks." > > Not at all. This looks like an English language issue to me: May be I misunderstood what you stated. > - All IGP attacks would have to be insider attacks, > because external packets are normally filtered anyway. I have mentioned cases where they may not be able to be filtered. This is an old discussion please go through the IPsec archives and you will get the gist. > - I am not aware of any IGP attacks ever occurring in the > deployed world. There might be some, but I am not aware > of any published reports during the past ~20 years. > - If someone has seen an actual active attack on any IGP, > that would be VERY interesting to learn more about. Fair enough!!! Like I said we do not leave the door open in the house because noone has broken into the house yet. :) >> Well we do not have to wait for the first attack to act, we need to >> react even before the attacks occur. You may have noted a similar move >> in all Security groups even though attacks themselves have not occured >> yet. > > Network operators have a range of mechanisms available now in shipping > routers. Which mechanisms, if any, make sense to deploy is entirely > up to their judgement -- based on their risk/threat model for their > specific deployment. > >> Also note we have to consider the havoc to the forwarded traffic that >> can be caused if the routing infrastructure is compromised. So the >> effect of an attack is more than just attacking an end user site. > > Again, there are a range of existing mechanisms that network operators > can choose to use -- and there seem to be no reports of any IGP attack > in the real world. Please note my basic comment mentioned above. >>> Fourth, the *only* goal of the various cryptographic IGP >>> authentication mechanisms (excepting: RFC-2154) always >>> has been to remove only the "passive attack" risks described >>> long ago in RFC-1704. Such passive attacks are trivially >>> easy to mount, even easier than a simple DOS attack, which >>> is why they are sensible to protect against. >> >> Agree partially. It is a goal but not the only goal of cryptographic >> mechanisms. > > You personally might have different goals for IGP authentication, > but the various mechanisms extant (excepting RFC-2154) were only > designed to protect against passive attacks (as described in RFC-1704). > > I have either authored or co-authored every one of those IGP mechanisms > (e.g. the OSPF MD5 mechanism is why I get the acknowledgement in the > OSPF RFCs). They protect against a limited set of issues. The > limitations are widely understood in the community. For example, > at the BOF held at IETF/Dublin, the entire room appeared to understood > from the beginning that the current mechanisms are very limited. I was > quite clear in my comments during that BOF that the current mechanisms > are limited. > > If one wants more, then the work that other folks have done with > "Digital Signatures" (RFC-2154) seems like the right direction to go. > That approach provides MUCH more comprehensive protections than > any other current mechanisms. (This is all a rehash of comments > I made during the KMART BOF at IETF/PHL, not all of which comments > made it into the minutes.) If you made comments in the KMART which were not shared, please share them with us. If you have some Digital Signature based algorithm in mind please bring it up in the right context in the right forum. We have had discussions about this in the SAAG group too. > IS-IS and RIP likely would benefit from having equivalent specifications > developed; for OSPF, RFC-2154 already exists. > > (I have no personal interest in developing such "Digital Signature" > specifications for either IS-IS or RIP, but perhaps other folks here > do. I think it would be helpful to have the specifications completed > and openly specified so that users who wanted something stronger > could ask for something specific.) > >>> Fifth, the existing cryptographic authentication mechanisms >>> are not really widely deployed operationally. Many enterprise >>> users don't enable any form of authentication. Some enable >>> clear-text passwords; relatively few bother to enable >>> cryptographic authentication. Among ISPs, security mechanisms >>> are more widely deployed, but even in that community the >>> existing cryptographic authentication mechanisms appear not >>> to be widely used today. This is not because operators/users >>> are silly or uninformed. Instead, this is because they are >>> performing sensible risk/threat analyses and deploying what >>> actually makes sense for their operational environments. >> >> Comments given above. > > None of which comments above address the text which you have quoted. > >>> % OSPF cryptographic sequence number spoofing or replay >>> >>> From a technical perspective, these are solved problems. >>> Please see RFC-2154. Note that the absence of commercial >>> implementations of RFC-2154 reflects the total absence >>> of user/operator concern about either of these issues, >>> along with user/operator concern about the complexity >>> of a digital signature approach. >> >> IPsec with Manual Keying still states there can be no Replay protection. > > RFC-2154 does not use IPsec. So a comment about IPsec > is orthogonal to the discussion. Please go read RFC-2154. The comments may be Orthogonal but if I am not mistaken they include the use of Public Key Cryptography. We have problems of getting to the PKI before we have the route etc, and this problem has been debated too. Can you discuss why a mechanism of using IPsec is not better than the mechanism you mention? I have suggested a way like using BTNS for the same. >>> There is only one known user with any interest in SHA >>> authentication for routing protocols. They have said >>> that the only reason for that interest is "policy compliance". >>> Even they have not yet indicated that SHA support is required >>> of their equipment suppliers. >> >> The only known user interest to your knowledge. > > Yes, of course -- to my own knowledge. > > Do you know of anyone other than US DoD that wants this ? > (US DoD are the only ones that I can identify, and they are > saying their interest is only for "policy reasons".) > > If so, which users ? which RFPs ? > > For that matter, are there any users/operators on this list > that have concrete plans to move to SHA for IGP authentication > anytime soon ? > >> As noted by the Routing AD's, IETF manadates we move out of support >> for MD5 and into supporting other algorithms as stated. > > Yes, the requirement is for algorithm agility, which we already had > with the older Keyed-MD5 mechanisms. The mechanisms themselves > were algorithm-independent, although only one algorithm happened > to be specified at the time (due to limited user interest). > > Algorithm agility is a fine thing, as I noted in a paper written > for IEEE Network [1], but it is different from urging folks > to change their deployed algorithms. I had suggested that > changing the deployed algorithm from MD5 to SHA seemed unwarranted. > You haven't addressed that comment. I said it is not mentioned in the draft. The draft is an issues draft and does not talk about using MD5 or SHA1, it gives issues with the current crypto mechanisms. >>> Further, there are no known shipping implementations of >>> SHA authentication for any IETF-specified IGP. >>> (I don't know of any that are even "in progress".) >> >> We know of a few including a big router vendor. :)) > > Please do name all of the names. :-) > I think it would be helpful for everyone to know which > implementations have already shipped and which might be > coming soon. Well we have disccused this and you are on the CC list for the same. I do not have contacts in all the vendors, so cannot tell you for now. Once the draft is to be made a standards track we can do the implementation report and get the data. Again this is an aside and this is not part of the draft. >>> Also, the concerns about collision attacks on MD5 (which >>> are not known to affect either Keyed-MD5 or HMAC-MD5) >>> are not fundamentally different from the concerns about >>> collision attacks on SHA. >> >> Agree. > > Given that you agree the concerns are the same, > then why does your draft push SHA over MD5 ? > >>> 1. Several published academic papers about SHA issues >>> are quite easily found by an online search: >>> >>> >>> 2. NIST is working to replace SHA anyway (Nov 2007 announcement) >>> >>> >>> >>> So it seems silly to urge users to move to a security mode >>> (e.g. SHA) that those users can't actually acquire or deploy, >>> and whose underlying algorithm itself is likely to be deprecated >>> in the near future by its own standards body (SHA is a NIST Federal >>> Information Processing Standard). >> >> The urge is to get into HMAC-SHA1 not SHA1. > > Moving to HMAC-SHA1 does NOT necessarily improve security > over current algorithms. > > Moving to HMAC-SHA1 does mean that the CPU on a router > receiving a DOS attack via some IGP would be more severely > impacted (because SHA1 is more computationally expensive > than MD5).[2] > > In fact, there are no known attacks (so far) upon any of these: > - Keyed MD5 > - HMAC MD5 > - HMAC SHA/SHA1/SHA2 > > [If someone knows of a published attack on any of the above, > please do post a full bibliographic citation here, so that WG > participants can go find/read the paper in question. > If some new discovery has happened, I'm personally quite keen > to learn about it. :-] I agree so am I and the rest of the world. > So I've shown in my earlier note that there are equivalent concerns > with aspects of both cryptographic hash functions specified > by the IETF: > - MD5 > - SHA/SHA1/SHA2 > > And we know from the URL I provided earlier that NIST is actively > moving to deprecate all use of SHA/SHA1, including HMAC-SHA1. > > So one can see that there is no obvious net gain for users moving > to HMAC-SHA for IGP authentication, relative to either HMAC-MD5 > or Keyed-MD5. Moreover, there is increased impact on the router CPU > (and hence the router control plane generally) of a prospective > DOS attack on IGP packets if any form of SHA is used.[2] > > And to repeat another central point: > > - Key management for IGP authentication really could benefit from > some IETF standards work. It would make any of this MUCH easier > to configure and deploy. MSEC and Kerberos are among possible > approaches to IGP key management. For this group, the role might > be to draft an "IGP KM Requirements" document for the other WGs > to work from. I agree we need to get a solution for this and we are seeing mechanisms that may help in such a case. Thanks Ran, Vishwas > > Yours, > > Ran > rja@extremenetworks.com > > > [1] R. Atkinson, "Toward a More Secure Internet", > IEEE Computer, Vol. 30, Number 1, January 1997. > > [2] One example DOS attack was presented in an IETF WG session > by someone else some years back (1990s). Basically, the > adversary creates a packet that is syntatically valid to > the IGP specification, then puts arbitrary bits into the > Authentication Data field of the packet, and sends it to > a router. The receiving router receives the packet and > the router CPU then performs expensive cryptographic computations > that are all wasted CPU cycles (because the bits in that > field were arbitrary) before tossing the DOS IGP packet. > Other DOS attacks exist, of course, this is just an example. > > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 16 15:40:25 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7435E3A68E0; Tue, 16 Dec 2008 15:40:25 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4A23A68E0 for ; Tue, 16 Dec 2008 15:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQsCFXMTnkMb for ; Tue, 16 Dec 2008 15:40:22 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id DFF023A68A9 for ; Tue, 16 Dec 2008 15:40:21 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so791677qwe.31 for ; Tue, 16 Dec 2008 15:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:subject :mime-version:date:references:x-mailer; bh=ZkBpezbbIANnn2LIKSS5FKO2axv0efQQRBiVN5Yb018=; b=xUR2gLcrC90ezDeKiFDxzWUabmtUUEyk1L5D3tuESqpL4gxBKH4spus2T1dUikwW8C G23L8aP8yQYToQOmnJeZRJFUiwjd8yBcXPNW68VpwwgwhaQ1HXyvBb1qGCa/AMtyJtnZ erZ/cnkWlSi4pMcdDoMY4Cnh0xZL338f0p/1U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:subject:mime-version:date:references :x-mailer; b=hbmPnZfR0z2mKKEi6h6GipKYFEro5wA7Lwk0UgBW/d95REZOtXnZrg9TR9el3l/Y2x lJNps0PMnDewPNMcbAd7XwJtR5lIznQt2Mes6UDy3agZ+aCgQqwB4jJykAc99y1fVMlz M4q5udDgcJ0IUZI36nuFmq8wr9CJJvf8Kd8vA= Received: by 10.214.114.17 with SMTP id m17mr63188qac.21.1229470813508; Tue, 16 Dec 2008 15:40:13 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 7sm1756229ywo.57.2008.12.16.15.40.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 15:40:13 -0800 (PST) Message-Id: <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 16 Dec 2008 18:40:10 -0500 References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 16 Dec 2008, at 14:18, Vishwas Manral wrote: > Let me again state that > this document lists issues with existing cryptographic mechanisms. It > is not a solutions document, if we have solutions like Digital > Signatures we can have the mechanisms. I'm not clear which document you are referring to. My comments were reactions to the meeting minutes, as the Subject line indicated and the quoted text indicated. OSPF with Digital Signatures is an existing mechanism (RFC-2154). Is it discussed at the same level of detail as other mechanisms ? > If you do not agree to the solutions drafts of > which you are a co-author (and the work is in > other working groups), we can see what can be done. I can't parse the above, terribly sorry. > Please see the discussion on the IPsec Maintainance working group. > Check the topic "Deep Inspecting ESP-NULL Packets" and the related > draft solutions currently being proposed. However this is not in the > scope of this document or discussion. If you have issues with this let > us discuss the same in the right forum. To the extent you are describing an operational security matter with routing protocols and IPsec, which seemed to be your prior claim, then that is indeed within charter for the IETF OPsec WG (i.e. here). > I opened the base OSPF RFC Page 242 please note that they talk about > only security when athentication is enabled. They do not delve into > issues that might occur with the security mechanisms themselves into > picture. Here are some references: RFC-2082 RFC-4822 RFC-5304 draft-rja-ospf-hmac-shs-00.txt [1] Some folks on this list might or might not have read: draft-ietf-isis-hmac-sha-07.txt draft-ietf-ospf-hmac-sha-03.txt draft-ietf-ospf-md5-02 [1] [1] A search engine is best to find this, as it is defunct. >>> Our aim is to bring out issues even when cryptographic >>> authentication is available. >> >> The limitations are generally already documented in the IGP >> authentication documents' "Security Considerations" sections. > No it isnt. Generally, they have been, for example in the references above. > Can you please map the RFC2328 security section with the > OSPF vulnerabilities mentioned. Please do the same exercise for BFD, > or for other protocols. It will be clear what we are talking about. RFC-2328, Page 243, makes a narrow precise claim: "...is believed to be secure against passive attacks and provide significant protection against active attacks." No claim that the mechanism is secure against all nor even against most active attacks is made by the OSPF RFC. Separately, the several mechanisms' various limitations are widely understood within the Internet community, as was evident throughout the KMART BOF. The discussion there was not so much about the current issues, which were believed to be well understood, as about possible futures. >> - All IGP attacks would have to be insider attacks, >> because external packets are normally filtered anyway. > I have mentioned cases where they may not be able to be filtered. This > is an old discussion please go through the IPsec archives and you will > get the gist. Which specific cases ? Please provide a URL for your note to the OPsec list where you detailed those cases. I have looked, and I can't find that note in the OPsec list web archives, terribly sorry. >> - I am not aware of any IGP attacks ever occurring in the >> deployed world. There might be some, but I am not aware >> of any published reports during the past ~20 years. >> - If someone has seen an actual active attack on any IGP, >> that would be VERY interesting to learn more about. > Fair enough!!! Thank you. So, for now, we don't know of any active attacks being undertaken against any IGP. There might have been some, I think we all agree, but we don't actually know of any. So we agree that we don't have any known active attacks, and that we have existing mechanisms that users believe are suitable for their threat environment. >> If one wants more, then the work that other folks have done with >> "Digital Signatures" (RFC-2154) seems like the right direction to go. >> That approach provides MUCH more comprehensive protections than >> any other current mechanisms. (This is all a rehash of comments >> I made during the KMART BOF at IETF/PHL, not all of which comments >> made it into the minutes.) > If you made comments in the KMART which were not shared, > please share them with us. (My last note to the OPsec list repeated the main comments from me that seem to be missing from the KMART meeting minutes.) > If you have some Digital Signature based algorithm in > mind please bring it up in the right context in the right forum. We > have had discussions about this in the SAAG group too. IETF OPsec is an appropriate forum to discuss both risks and possible future directions for IGPs in general. (Of course, any protocol specification work would need to be undertaken elsewhere. :-) >> RFC-2154 does not use IPsec. So a comment about IPsec >> is orthogonal to the discussion. Please go read RFC-2154. > > The comments may be Orthogonal but if I am not mistaken they include > the use of Public Key Cryptography. We have problems of getting to the > PKI before we have the route etc, and this problem has been debated > too. Can you discuss why a mechanism of using IPsec is not better than > the mechanism you mention? Ah, try to change the topic and ask a different question, rather than read RFC-2154 and comment upon it. Interesting. In general, I have long suggested that AH is a reasonable approach to protecting IGPs. AH, or for that matter ESP, isn't perfect either, but using IPsec is different and also seems like a reasonable approach that someone might take. Historically, one of the primary reasons that the IGPs have their own mechanisms was that AH/ESP availability in routers during the middle 1990s was either limited or non-existent (depending on which router platform one considers). Had IPsec been widely available in routers, and implemented in a way that facilitated its use with IGP authentication, the IETF might well have avoided going down the path of per-IGP authentication mechanisms. The same basic history applies to TCP MD5 to protect BGP, and explains why AH/ESP aren't widely used today to protect BGP. (And, just to be clear, I have no issues with anyone proposing or defining new mechanisms. My own sense -- opinion -- is that for a new mechanism to be "interesting" it either needs to be a lot simpler to deploy than what is on the shelf right now and with similar risk reduction properties OR the new mechanism needs to provide significantly better risk reduction properties. RFC-2154 provides significantly better risk reduction properties than any of the existing mechanisms. Ultimately, the market decides what gets deployed, of course.) I don't think, however, that the facts available right now justify this WG formally encouraging users to move to SHA (or HMAC-SHA) authentication from some other existing IGP authentication approach. > I have suggested a way like using BTNS for the same. Great. It is always good to have more ideas for the community to consider. > I said it is not mentioned in the draft. The draft is an issues draft > and does not talk about using MD5 or SHA1, it gives issues with the > current crypto mechanisms. My comments were on the meeting minutes, as the Subject line and the text I quoted indicated, not on any particular draft. I'm unclear which draft you are referring to above. > Well we have disccused this and you are on the CC list for the same. I > do not have contacts in all the vendors, so cannot tell you for now. I haven't seen any email indicating that anyone was actually implementing any of the SHA mechanisms. Perhaps that note got lost in transit someplace. > Once the draft is to be made a standards track we can do the > implementation report and get the data. Again this is an aside and > this is not part of the draft. Users would be interested to know whether/when implementations are likely to exist. The OPsec meeting minutes indicated (perhaps just confusing wording ?) that a proposal was made that this OPsec WG should encourage all users to move to HMAC-SHA -- which is very difficult to do if multiple implementations are not readily available. >>> The urge is to get into HMAC-SHA1 not SHA1. >> >> Moving to HMAC-SHA1 does NOT necessarily improve security >> over current algorithms. >> >> Moving to HMAC-SHA1 does mean that the CPU on a router >> receiving a DOS attack via some IGP would be more severely >> impacted (because SHA1 is more computationally expensive >> than MD5).[2] >> >> In fact, there are no known attacks (so far) upon any of these: >> - Keyed MD5 >> - HMAC MD5 >> - HMAC SHA/SHA1/SHA2 >> >> [If someone knows of a published attack on any of the above, >> please do post a full bibliographic citation here, so that WG >> participants can go find/read the paper in question. >> If some new discovery has happened, I'm personally quite keen >> to learn about it. :-] > > I agree so am I and the rest of the world. So you agree above that HMAC-SHA is not necessarily stronger, and has similar properties to the existing mechanisms -- so far as any of us are aware right now. And we all hope that if anyone hears otherwise, they will share that information here. To Summarise: From the meeting minutes, and given the agreement just above, it seems that the proposal discussed in the meeting minutes was to encourage users to move to a mechanism that (1) isn't obviously better and that (2) we know relies upon algorithms (i.e. SHA) that NIST is in the process of deprecating (due to concerns about SHA that are equivalent to the concerns about MD5). The only reason that I know of to move to SHA is to comply with some local organisational policy. That policy-compliance reasoning is what drove the creation of RFC-4822, pure and simple. So it seems non-obvious to me that this WG should make a recommendation that users migrate to HMAC-SHA mechanisms in preference to other mechanisms. Separately, I'm pleased that there is agreement that work on Key Management for IGPs would be useful. An "IGP key management requirements" draft might be a reasonable place for someone to start. Yours, Ran rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 16 16:16:50 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F378228C137; Tue, 16 Dec 2008 16:16:49 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32FD13A6866 for ; Tue, 16 Dec 2008 16:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeOPndFyV3AU for ; Tue, 16 Dec 2008 16:16:46 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 1FF673A6818 for ; Tue, 16 Dec 2008 16:16:45 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so1587540fga.41 for ; Tue, 16 Dec 2008 16:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=MLbzk/OManHvJ36A1M5qRaCSGNqfR8e1TfDiBNs831M=; b=RBBGpWXhHXM8qh21gXdE2expayK+unpY6TPmqBd85qfZQPmTe8cIoE0O45ufxnjARe oXNoKNGPbl558KcjWu60wOIAxw3+YbCfCLPewAbyVJBdFUhFdT9i7l87yKI+KSijR8Pn 001WuZfRhjUxWCu9syOoSR2OG3JpX+l3cse1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=tDYFuLnMp/jvI9dxN8jzhMCJO1tc6se9GDEQyF4IK5kkGvO0v2NbjVYHP0dxiIVm91 WtEN+Uus7ErnV6zQu1z1PGJ+uOwlwh93IsQR/BTNxrHNoSN6C9boyJZ3z37gEEy5r4Yi UGyTYSonCKiWigO1KvTdAcVHfWkAearh75A+Y= Received: by 10.86.60.14 with SMTP id i14mr52346fga.70.1229472997771; Tue, 16 Dec 2008 16:16:37 -0800 (PST) Received: by 10.86.70.17 with HTTP; Tue, 16 Dec 2008 16:16:37 -0800 (PST) Message-ID: <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> Date: Tue, 16 Dec 2008 16:16:37 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, Thanks for the conclusion, but the talk here is about 2 documents. The first document is about "Issues with crypto mechanisms in existing routing protocols" and the second document is the support of a minimum set of crypto algorithms to get interoperability because multiple Crypto Algorithms are currently supported for the same protocol. This is in line with what has been done in IPsec. What you seem to state is whether a particular crypto algorithm is better than the other for the IGP cases. The documents about adding other crypto algorithm support for IGP is already part of the respective IGP working group. You have been added as a co-author of one such draft and have authored another one. If you have issues regarding this we can discuss this but the IGP working group is a part of the document. Please raise the issues in the correct forum. If my language is not clear, do let me know if we can discuss the same in Hindi, Kumaoni, Gujarati or any other language that I know. I am sorry I am not as well versed in English. :)) > Separately, I'm pleased that there is agreement that work on > Key Management for IGPs would be useful. An "IGP key management > requirements" draft might be a reasonable place for someone to start. Yes there has always been consensus and like I said the same has been talked about multiple times in the SAAG list. If you have a solution please propose it in the right forum and we can work on this. Thanks again, Vishwas On Tue, Dec 16, 2008 at 3:40 PM, R Atkinson wrote: > > On 16 Dec 2008, at 14:18, Vishwas Manral wrote: >> >> Let me again state that >> this document lists issues with existing cryptographic mechanisms. It >> is not a solutions document, if we have solutions like Digital >> Signatures we can have the mechanisms. > > I'm not clear which document you are referring to. > > My comments were reactions to the meeting minutes, > as the Subject line indicated and the quoted text indicated. > > OSPF with Digital Signatures is an existing mechanism (RFC-2154). > Is it discussed at the same level of detail as other mechanisms ? > >> If you do not agree to the solutions drafts of >> which you are a co-author (and the work is in >> other working groups), we can see what can be done. > > I can't parse the above, terribly sorry. > >> Please see the discussion on the IPsec Maintainance working group. >> Check the topic "Deep Inspecting ESP-NULL Packets" and the related >> draft solutions currently being proposed. However this is not in the >> scope of this document or discussion. If you have issues with this let >> us discuss the same in the right forum. > > To the extent you are describing an operational security matter > with routing protocols and IPsec, which seemed to be your prior claim, > then that is indeed within charter for the IETF OPsec WG (i.e. here). > >> I opened the base OSPF RFC Page 242 please note that they talk about >> only security when athentication is enabled. They do not delve into >> issues that might occur with the security mechanisms themselves into >> picture. > > Here are some references: > RFC-2082 > RFC-4822 > RFC-5304 > draft-rja-ospf-hmac-shs-00.txt [1] > > Some folks on this list might or might not have read: > draft-ietf-isis-hmac-sha-07.txt > draft-ietf-ospf-hmac-sha-03.txt > draft-ietf-ospf-md5-02 [1] > > [1] A search engine is best to find this, as it is defunct. > >>>> Our aim is to bring out issues even when cryptographic >>>> authentication is available. >>> >>> The limitations are generally already documented in the IGP >>> authentication documents' "Security Considerations" sections. >> >> No it isnt. > > Generally, they have been, for example in the references above. > >> Can you please map the RFC2328 security section with the >> OSPF vulnerabilities mentioned. Please do the same exercise for BFD, >> or for other protocols. It will be clear what we are talking about. > > RFC-2328, Page 243, makes a narrow precise claim: > > "...is believed to be secure against passive attacks and > provide significant protection against active attacks." > > No claim that the mechanism is secure against all nor > even against most active attacks is made by the OSPF RFC. > > Separately, the several mechanisms' various limitations > are widely understood within the Internet community, > as was evident throughout the KMART BOF. The discussion > there was not so much about the current issues, which were > believed to be well understood, as about possible futures. > >>> - All IGP attacks would have to be insider attacks, >>> because external packets are normally filtered anyway. >> >> I have mentioned cases where they may not be able to be filtered. This >> is an old discussion please go through the IPsec archives and you will >> get the gist. > > Which specific cases ? > > Please provide a URL for your note to the OPsec list > where you detailed those cases. I have looked, and > I can't find that note in the OPsec list web archives, > terribly sorry. > >>> - I am not aware of any IGP attacks ever occurring in the >>> deployed world. There might be some, but I am not aware >>> of any published reports during the past ~20 years. >>> - If someone has seen an actual active attack on any IGP, >>> that would be VERY interesting to learn more about. >> >> Fair enough!!! > > Thank you. So, for now, we don't know of any active attacks > being undertaken against any IGP. There might have been some, > I think we all agree, but we don't actually know of any. > > So we agree that we don't have any known active attacks, > and that we have existing mechanisms that users believe > are suitable for their threat environment. > >>> If one wants more, then the work that other folks have done with >>> "Digital Signatures" (RFC-2154) seems like the right direction to go. >>> That approach provides MUCH more comprehensive protections than >>> any other current mechanisms. (This is all a rehash of comments >>> I made during the KMART BOF at IETF/PHL, not all of which comments >>> made it into the minutes.) > >> If you made comments in the KMART which were not shared, >> please share them with us. > > (My last note to the OPsec list repeated the main comments from me > that seem to be missing from the KMART meeting minutes.) > >> If you have some Digital Signature based algorithm in >> mind please bring it up in the right context in the right forum. We >> have had discussions about this in the SAAG group too. > > IETF OPsec is an appropriate forum to discuss both risks and > possible future directions for IGPs in general. (Of course, > any protocol specification work would need to be undertaken > elsewhere. :-) > >>> RFC-2154 does not use IPsec. So a comment about IPsec >>> is orthogonal to the discussion. Please go read RFC-2154. >> >> The comments may be Orthogonal but if I am not mistaken they include >> the use of Public Key Cryptography. We have problems of getting to the >> PKI before we have the route etc, and this problem has been debated >> too. Can you discuss why a mechanism of using IPsec is not better than >> the mechanism you mention? > > Ah, try to change the topic and ask a different question, > rather than read RFC-2154 and comment upon it. Interesting. > > In general, I have long suggested that AH is a reasonable approach > to protecting IGPs. AH, or for that matter ESP, isn't perfect > either, but using IPsec is different and also seems like a > reasonable approach that someone might take. > > Historically, one of the primary reasons that the IGPs have their > own mechanisms was that AH/ESP availability in routers during the > middle 1990s was either limited or non-existent (depending on > which router platform one considers). Had IPsec been widely > available in routers, and implemented in a way that facilitated > its use with IGP authentication, the IETF might well have avoided > going down the path of per-IGP authentication mechanisms. > The same basic history applies to TCP MD5 to protect BGP, > and explains why AH/ESP aren't widely used today to protect BGP. > > (And, just to be clear, I have no issues with anyone proposing > or defining new mechanisms. My own sense -- opinion -- is that > for a new mechanism to be "interesting" it either needs to be > a lot simpler to deploy than what is on the shelf right now > and with similar risk reduction properties OR the new mechanism > needs to provide significantly better risk reduction properties. > RFC-2154 provides significantly better risk reduction properties > than any of the existing mechanisms. Ultimately, the market > decides what gets deployed, of course.) > > I don't think, however, that the facts available right now > justify this WG formally encouraging users to move to SHA > (or HMAC-SHA) authentication from some other existing IGP > authentication approach. > >> I have suggested a way like using BTNS for the same. > > Great. It is always good to have more ideas for the > community to consider. > >> I said it is not mentioned in the draft. The draft is an issues draft >> and does not talk about using MD5 or SHA1, it gives issues with the >> current crypto mechanisms. > > My comments were on the meeting minutes, as the Subject line and the > text I quoted indicated, not on any particular draft. > > I'm unclear which draft you are referring to above. > >> Well we have disccused this and you are on the CC list for the same. I >> do not have contacts in all the vendors, so cannot tell you for now. > > I haven't seen any email indicating that anyone was actually > implementing any of the SHA mechanisms. Perhaps that note > got lost in transit someplace. > >> Once the draft is to be made a standards track we can do the >> implementation report and get the data. Again this is an aside and >> this is not part of the draft. > > Users would be interested to know whether/when implementations > are likely to exist. > > The OPsec meeting minutes indicated (perhaps just confusing wording ?) > that a proposal was made that this OPsec WG should encourage all users > to move to HMAC-SHA -- which is very difficult to do if multiple > implementations are not readily available. > >>>> The urge is to get into HMAC-SHA1 not SHA1. >>> >>> Moving to HMAC-SHA1 does NOT necessarily improve security >>> over current algorithms. >>> >>> Moving to HMAC-SHA1 does mean that the CPU on a router >>> receiving a DOS attack via some IGP would be more severely >>> impacted (because SHA1 is more computationally expensive >>> than MD5).[2] >>> >>> In fact, there are no known attacks (so far) upon any of these: >>> - Keyed MD5 >>> - HMAC MD5 >>> - HMAC SHA/SHA1/SHA2 >>> >>> [If someone knows of a published attack on any of the above, >>> please do post a full bibliographic citation here, so that WG >>> participants can go find/read the paper in question. >>> If some new discovery has happened, I'm personally quite keen >>> to learn about it. :-] >> >> I agree so am I and the rest of the world. > > So you agree above that HMAC-SHA is not necessarily stronger, > and has similar properties to the existing mechanisms -- > so far as any of us are aware right now. > > And we all hope that if anyone hears otherwise, they will share > that information here. > > To Summarise: > > From the meeting minutes, and given the agreement just above, > it seems that the proposal discussed in the meeting minutes was > to encourage users to move to a mechanism that (1) isn't obviously > better and that (2) we know relies upon algorithms (i.e. SHA) > that NIST is in the process of deprecating (due to concerns > about SHA that are equivalent to the concerns about MD5). > > The only reason that I know of to move to SHA is to comply > with some local organisational policy. That policy-compliance > reasoning is what drove the creation of RFC-4822, pure and > simple. > > So it seems non-obvious to me that this WG should make a > recommendation that users migrate to HMAC-SHA mechanisms > in preference to other mechanisms. > > Separately, I'm pleased that there is agreement that work on > Key Management for IGPs would be useful. An "IGP key management > requirements" draft might be a reasonable place for someone to start. > > Yours, > > Ran > rja@extremenetworks.com > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 16 16:20:44 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB20928C1D6; Tue, 16 Dec 2008 16:20:44 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0EB228C1D6 for ; Tue, 16 Dec 2008 16:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKN5TEbg4cLU for ; Tue, 16 Dec 2008 16:20:42 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 97A6D28C1D5 for ; Tue, 16 Dec 2008 16:20:41 -0800 (PST) Received: by bwz14 with SMTP id 14so4820432bwz.13 for ; Tue, 16 Dec 2008 16:20:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=etWkFJlf1QbRSL8M1FDc+XkqDwVLBb+uX6xgWFDsDGQ=; b=PYZcklVPFigc7xKsiPT1FFe0WUpvdDc5cblsRA2JzofnYCsB/oPRgheOZ4yoi9I+Td kB+zibPtYvDNA07joCuLMj7qJLfEgvw5JWUXlurP5YgXBn+zAtsR3L/KCuaHKYCdNYtA zIFkTMAOBdOk18ha+VDZDEtT2+9A80AEqdbO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=O6CoI4xJ+nmn3cqgTE6qPuEP+1HIoCWlGCRdjTU1T3uO+l2+KmoV/rq0MchnJdeXnW TEyu06s1Dj0fz9g114QdDOSfVFu+7fjGO2k5cdkGvdnvFPx8mmDLjanC+bm+M1ocEN15 mv7Bzv5i6Kp5bUAKQdvVrppqIHkxfDCNIr3eM= Received: by 10.103.171.20 with SMTP id y20mr17575muo.122.1229473233099; Tue, 16 Dec 2008 16:20:33 -0800 (PST) Received: by 10.103.160.12 with HTTP; Tue, 16 Dec 2008 16:20:33 -0800 (PST) Message-ID: <92c950310812161620j7d8aaa16m553940edadbe6d8f@mail.gmail.com> Date: Wed, 17 Dec 2008 05:50:33 +0530 From: "Glen Kent" To: "RJ Atkinson" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org I don't understand your concern. When I read the draft-ietf-opsec-routing-protocols-crypto-issues for the first time what it told me was that Yes, using cryptographic authentication is all fine but there can still be some attacks despite using such schemes. What you're saying is that the attackers need not go that far and that there are simpler ways to launch DoS attacks against the routers. Agreed, so what? This doesn't make the existing issues with crypto protection any less criminal? This also doesn't preclude the need to document the issues that can exist with the current authentication mechanisms. I could have understood your dissent if a WG were proposing solutions to the problems cited in the issues draft on the grounds that those are not needed, however, a draft such as this needs to be present so that the community knows that cryptographic protection as offered by IGPs is not a panacea to all security problems - ISSUES still exist! OPSEC must only document such issues. Its up to the other WGs to decide whether they want to act on it or not. Glen On Tue, Dec 16, 2008 at 9:34 PM, RJ Atkinson wrote: > All, > > This note is a response to parts of the above email. > (I was presenting a paper at a research conference, > so I was unable to attend IETF/MSP in person and > make these comments then/there. I can't be in > two cities at the same time. :-) > > First, let me observe that IGP attacks are all insider attacks. > Sites routinely block IGP packets from entering from outside > their administrative domain. (This would be a sensible thing > for OPsec to recommend if it hasn't already done so.) > Similarly, ISPs normally block IGP packets from arriving > on customer-facing interfaces or other exterior interfaces. > > Second, prospective attackers are both smart and lazy. They > are not likely to use a computationally expensive attack > vector (e.g. something cryptographic) when a simpler/easier > attack (e.g. DoS on the router CPU) exists. > > Third, I am not aware of any active attacks on any deployed > IGP. I've worked at more than one network operator in the > past, and for multiple equipment suppliers. I've never heard > of even one. If active attacks were widespread or common, > then they would have received much more reporting in the > trade press (as different from the zero reports that I've > seen over the past ~20 years). > > Fourth, the *only* goal of the various cryptographic IGP > authentication mechanisms (excepting: RFC-2154) always > has been to remove only the "passive attack" risks described > long ago in RFC-1704. Such passive attacks are trivially > easy to mount, even easier than a simple DOS attack, which > is why they are sensible to protect against. > > Fifth, the existing cryptographic authentication mechanisms > are not really widely deployed operationally. Many enterprise > users don't enable any form of authentication. Some enable > clear-text passwords; relatively few bother to enable > cryptographic authentication. Among ISPs, security mechanisms > are more widely deployed, but even in that community the > existing cryptographic authentication mechanisms appear not > to be widely used today. This is not because operators/users > are silly or uninformed. Instead, this is because they are > performing sensible risk/threat analyses and deploying what > actually makes sense for their operational environments. > > % OSPF cryptographic sequence number spoofing or replay > > From a technical perspective, these are solved problems. > Please see RFC-2154. Note that the absence of commercial > implementations of RFC-2154 reflects the total absence > of user/operator concern about either of these issues, > along with user/operator concern about the complexity > of a digital signature approach. > % Need to move from md5 to stronger crypto. > There is no obvious reason for a site to move from either > Keyed-MD5 or HMAC-MD5 to something else. There are no known > vulnerabilities in either Keyed-MD5 or HMAC-MD5 as used by > IETF routing protocols. By contrast, moving to SHA will > significantly increase a router's vulnerability to DOS attacks, > while providing negligible decrease in risk. (Also see > the comments 3 paragraphs down about SHA's own issues.) > > There is only one known user with any interest in SHA > authentication for routing protocols. They have said > that the only reason for that interest is "policy compliance". > Even they have not yet indicated that SHA support is required > of their equipment suppliers. > > Further, there are no known shipping implementations of > SHA authentication for any IETF-specified IGP. (I don't > know of any that are even "in progress".) > > Also, the concerns about collision attacks on MD5 (which > are not known to affect either Keyed-MD5 or HMAC-MD5) > are not fundamentally different from the concerns about > collision attacks on SHA. > > 1. Several published academic papers about SHA issues > are quite easily found by an online search: > > > 2. NIST is working to replace SHA anyway (Nov 2007 announcement) > > > So it seems silly to urge users to move to a security mode > (e.g. SHA) that those users can't actually acquire or deploy, > and whose underlying algorithm itself is likely to be deprecated > in the near future by its own standards body (SHA is a NIST Federal > Information Processing Standard). > > % Keys shared across the broadcast domain, > % need to move to a stronger key identifier. > > 1. All IGPs multicast/broadcast their update packets, > so sharing a key across that same multicast/broadcast > domain is not a silly approach. > > 2. Adding a Key-ID does not actually increase the > security of anything. It can make it slightly simpler > for an implementation to locate the correct Security > Association to use in attempting to authenticate a > received packet, however the most widely deployed > implementations *ignore* the Key-ID and instead just > try all configured and valid SAs on the router. > > % For OSPFv3 relies on ipsec, because manual key sequence number, > % replay protection cannot be used. > > See comment up top with reference to RFC-2154. > > % IS-IS MD5 but no sequence number not notion of keyid > % for pdu key must be validated. > > See previous comments. > > Separately, IS-IS is carried directly over the link-layer, > so off-link attacks are automatically precluded. This means > that the only possible threat model is an on-link insider. > There are simpler/easier attacks (e.g. DOS) on the routing > infrastructure. So adding a sequence number doesn't really matter. > Again, the KeyID is merely an implementer convenience, rather than > some form of risk reduction. > > % Need to update from md5 > > There are no known attacks on either Keyed-MD5 or HMAC-MD5, > so there is no obvious reason for a user/operator to deploy > SHA authentication (or OSPF with Digital Signatures). Also > recall that SHA itself has published issues. > > % ripv2, no authentication of ip or udp headers. can change > % source address and receiver will still think it's a valid > % neighbor > > If MD5 authentication is enabled, packets can't be forged. > > If one wants something stronger, a completely different > "Digital Signature" approach (analagous to that described > in RFC-2154 for OSPF) is the right direction to head (as > the RIPv2 Authentication RFC already says). > > None of the recent documents in IGP authentication make any moves > towards use of Digital Signatures, probably because there is no > visible user/operator interest in this. > > % We need a distributed keyserver and the ospf guys need it > % even more than we do. > > This is entirely believable, not because it increases security, > but because it solves real-world operational/deployment issues. > > One logical approach to this would be to use a key distribution > center (e.g. Kerberos). While Kerberos can be complex to deploy > on all hosts in a large campus network, largely because of varying > administrative domains, Kerberos is reportedly straight forward > to deploy among all routers within a single administrative domain > (although obviously it requires ordinary planning and care in > deployment). > > At least one very large multi-continent ISP had deployed Kerberos > over 10 years ago. Two widely deployed brands of router have > already shipped Kerberos support, so this approach might be > easier to get router implementers to support. Folks interested > in this might want to put together a "requirements" draft as a first step. > > % gathering a group of people to identify the needs and go and > % beat on msec > > Agreed. Using work from the IETF MSEC WG is another reasonable > approach to adding key management for IGPs. > > % Second draft, minimum cryptographic requirements. the fact is > % cryptographic algorithms continue to be attacked. we need to > % keep track of this. the idea of this document is to keep > % modifying it but to track the minimum requirements for interoperability > > I see this document as largely valueless. Most users/operators > aren't enabling any form of cryptographic authentication today, > because their risk/threat environment makes that not sensible > for their operational domain. > > The market (i.e. users and RFPs) drive which IETF specifications > are widely implemented by equipment suppliers. The days when > IETF recommendations were widely and automatically obeyed by > product managers at many equipment vendors has been gone > for more than a decade now. > > I am not aware of *any* known attacks on any deployed IGP with > any form of cryptographic authentication configured. If someone > has actually seen such himself/herself, please provide the details > here as that would be significant news. > > Again, there are no known vulnerabilities in either Keyed-MD5 or > HMAC-MD5, and it is not obvious that SHA is necessarily either > better or stronger (although it is measurably more computationally > expensive for the router trying to authenticate a received packet). > So there is no obvious security reason for an operational > site to deploy something other than MD5. Heck, many sites don't even > go that far today because their risk/threat model doesn't need it. > > In summary, the actual *operational* issue that this group can > make an impact with would be to specify some requirements (from > an operator/user perspective) for IGP authentication key management > (so that IGP authentication is easier to configure/deploy/manage), > and then work with other appropriate groups (e.g. Kerberos, MSEC) > to have those groups add the necessary capabilities in their > protocols. It seems to me that this would be a much better focus. > > If folks really think that the current approaches to IGP authentication > aren't adequate, then they really ought to consider working on adding > "Digital Signature" support for RIPv2 + IS-IS and they also ought > to be asking their router suppliers to implement RFC-2154 support. > > Yours, > > Ran Atkinson > rja@extremenetworks.com > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 16 16:53:36 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559433A6999; Tue, 16 Dec 2008 16:53:36 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 228BD3A6999 for ; Tue, 16 Dec 2008 16:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USJBhledb7mT for ; Tue, 16 Dec 2008 16:53:34 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 0ED333A6870 for ; Tue, 16 Dec 2008 16:53:33 -0800 (PST) Received: by qyk4 with SMTP id 4so3488417qyk.13 for ; Tue, 16 Dec 2008 16:53:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=bjvDJpKMzw5EGndhZvbZ8YUrpZVz6tGOD5Q8NOPwfT0=; b=oZeB9l7vimGsNUJ96fdWRz2GoSR9p43x07MjJJ/6BgVb0qhVvwxusVGzSJG81zvc3f 8MiA9+prveEvWulSR8Qjv2hRWI8Sad84V1SWG30j0xDcP0U4b4eBustSnjHgP3h5j+kK cAIBUQPz+kfpV3BnA3ap2fH5CMCs46uCP7C/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=QisbV37Trhu6sAw2rl4UWPIAA69zsW+nae5O19RJTaIUN9k+QnK+mc+hTqecPqnSoG 6N9qk+KOY6m2fswaJhokNJfHhI1Q49knblcGB67h9nrO7NmdLD63J6l68lHCIsDDkmOy wka0aGk6UFEl5i6URWHWzMmUFr1iJbNzlJUJo= Received: by 10.214.183.17 with SMTP id g17mr85739qaf.265.1229475205846; Tue, 16 Dec 2008 16:53:25 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 9sm1896017yws.28.2008.12.16.16.53.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 16:53:25 -0800 (PST) Message-Id: <12201E12-8A0B-4FBE-95A9-5C8B23DA46EC@gmail.com> From: R Atkinson To: "Glen Kent" In-Reply-To: <92c950310812161620j7d8aaa16m553940edadbe6d8f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 16 Dec 2008 19:53:23 -0500 References: <92c950310812161620j7d8aaa16m553940edadbe6d8f@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 16 Dec 2008, at 19:20, Glen Kent wrote: > I don't understand your concern. I have no concern with the WG documenting any issues, provided: - they really are technical issues rather than opinion, - the analysis really is comprehensive, including a threat model, - the analysis also discusses existing mitigations, and - the analysis covers all such authentication mechanism, including for example RFC-2154, not just some of them. (For an individual submission rather than a WG document, of course, none of the above caveats would apply, as individuals can say whatever they wish, true or not, in a personal informational RFC. :-) As my notes have tried (and perhaps failed, sigh) to make clear, the focus of my concerns are: 1) An apparent proposal, according to the WG minutes, to have the OPsec WG recommend that users migrate to using SHA-based mechanisms. There are not solid technical grounds to recommend/prefer SHA approaches over MD5 approaches (or the reverse: it isn't obvious that MD5 is better either). 2) Erroneous claims in the meeting minutes that SHA-based approaches are better than the existing MD5-based mechanisms. The approaches are very slightly different, but as the URLs I provided much earlier today make clear, SHA has issues in the published literature just as MD5 does, AND NIST is actively moving to deprecate SHA/SHA-1/ SHA-2. Yours, Ran rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 16 17:03:58 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70A703A690D; Tue, 16 Dec 2008 17:03:58 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3F83A690D for ; Tue, 16 Dec 2008 17:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6PZveZrUZ73 for ; Tue, 16 Dec 2008 17:03:56 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 442983A6813 for ; Tue, 16 Dec 2008 17:03:56 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so1424276yxg.49 for ; Tue, 16 Dec 2008 17:03:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=wrr3E25/+Qsnhe3J2w7aqofx8p/tluvyxkCcnFcUDFg=; b=CV0BaFXWoDOTChdwSPZDtxQnbY9Bdzsjp/+yOdRAIYL2XGL+tFr6Q7bFj3nwDQIQiL 7uy0bJe+dBBKGAit6SbfAWgD5PTm0SRl9EWKOHmrepfUfA4oruw/e+DvCudN+SNYh8VQ xDdgtKkX7IM/910hm0DbMRtOx7dLuzBEznD3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=C0BcJ2HN5gVK/MbT//3ImeSfQXH7sc5XYZ9fJgIuFggdYJL5nHL/cMo/2IJnfHR8pm lku6kaMbC/N0aOWKZtAozys1CPgv3SELtXoU5+d0miERlLnjBBHx3ZUsVIlSCIIXV408 jhAF3ocfnL4OroZXFMunB60cJNAVuqZeN2fz4= Received: by 10.64.242.4 with SMTP id p4mr74664qbh.84.1229475827837; Tue, 16 Dec 2008 17:03:47 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id p6sm41236qbp.14.2008.12.16.17.03.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 17:03:47 -0800 (PST) Message-Id: <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 16 Dec 2008 20:03:45 -0500 References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 16 Dec 2008, at 19:16, Vishwas Manral wrote: > Thanks for the conclusion, but the talk here is about 2 documents. Actually, as the Subject line and my quotes from my very first note made clear, all of my notes have solely been responses to the *OPsec meeting minutes*. I object to the assertions in those minutes that: - the SHA approaches are better/stronger than MD5 approaches. [We have agreed that the evidence does NOT support such a claim -- which claim appears to be in the meeting minutes.] - the WG should recommend/encourage/promote SHA approaches over MD5 approaches. [which claim again appears to be in the meeting minutes] > What you seem to state is whether a particular crypto algorithm is > better than the other for the IGP cases. I can't parse that, so I don't know what you mean. Please re-phrase. > Please raise the issues in the correct forum. I have been all along. Please discontinue incorrect assertions that this is not an appropriate forum for discussing items in the OPsec WG meeting minutes. All day I've been raising operational security issues within the OPsec WG. > If my language is not clear, do let me know if we can discuss the same > in Hindi, Kumaoni, Gujarati or any other language that I know. I am > sorry I am not as well versed in English. :)) Fair. Each of us do our best. :-) I am a polyglot [RFC-2130], but I also don't know any south Asian languages, terribly sorry. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 16 17:28:25 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1129E3A6841; Tue, 16 Dec 2008 17:28:25 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD95F3A6841 for ; Tue, 16 Dec 2008 17:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM3xeqhP6t+8 for ; Tue, 16 Dec 2008 17:28:24 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id CA3993A676A for ; Tue, 16 Dec 2008 17:28:23 -0800 (PST) Received: by qyk4 with SMTP id 4so3501238qyk.13 for ; Tue, 16 Dec 2008 17:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=HY2qc4FqwiU9OpOfizPo/irb1EIBJMICG/uhiN+/VGo=; b=ME51jjDXEMfQ7uzYNx7E2obgkef+IZ4B6RVopGXR+W0OP21YoimdPk/SoPuCRm5hw3 ywS3ZtkuV87NKAKqNu0KJL4cZiqRgu9oRTFkJh92G5H2QhBh4vpPirsXeIeCU/Zc5uvH TMQ0YGSnc4s6+oKEpUcwjketIesMN2CG1wyo8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=rG93A3xaN89KxnMnlcf2tEwJDW8E/Ho/eW/I4Iot109C46kgRzrSD5xWA5BwB9fHQJ c6FGx7YnjpLDAmL/nFuCwCpVxUQKU8g5yR4xKUqs0ImV0PWmJkdWwgTIQcDsd1MEubIu ZUcSeFk+4hXilzBU/j0LgNQe2zOiLYa42zFxI= Received: by 10.214.113.12 with SMTP id l12mr138726qac.151.1229477293937; Tue, 16 Dec 2008 17:28:13 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 5sm4042696ywd.41.2008.12.16.17.28.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 17:28:13 -0800 (PST) Message-Id: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> From: R Atkinson To: opsec@ietf.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 16 Dec 2008 20:28:11 -0500 X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Vishwas, Can we please get answers to these questions -- which in fact are entirely on topic for the OPsec WG, since they are all operational security matters ? (Single quotes are from me; double-quotes are from Vishwas' earlier emails.) 1: OSPF with Digital Signatures > OSPF with Digital Signatures is an existing mechanism (RFC-2154). > Is it discussed at the same level of detail as other mechanisms ? 2: Filtering of IGP packets >> I have mentioned cases where they may not be able to be filtered. > > Which specific cases ? Please provide a URL for your note to the OPsec > list where you detailed those cases. I have looked, and I can't find > that note in the OPsec list web archives, terribly sorry. This is an immediate operational security issue, if true. I'm sure I'm not the only person who'd like to understand the claim more precisely. 3: User interest in SHA mechanisms for IGP authentication > Do you know of anyone other than US DoD that wants this ? > (US DoD are the only ones that I can identify, and they are > saying their interest is only for "policy reasons".) > > If so, which users ? which RFPs ? 4: Availability of SHA mechanisms for IGP authentication > Further, there are no known shipping implementations of > SHA authentication for any IETF-specified IGP. > (I don't know of any that are even "in progress".) >> We know of a few including a big router vendor. :)) Which ? How many ? When ? Are they shipping now or in progress now ? 5: Claims made by existing IGP authentication documents >> However if you see most drafts "security considerations" section, >> they state that using cryptographic authentication is a panicia for >> all evils. I can't find even one RFC or I-D that says anything similar to "using cryptographic authentication is a panacea for all evils". I checked a bunch of documents, which I enumerated in an earlier email; none contained any such language. Which specific document does this ? and on which page ? Thanks, Ran _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 16 17:59:39 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6376F3A68CC; Tue, 16 Dec 2008 17:59:39 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 706473A68CC for ; Tue, 16 Dec 2008 17:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRqz6joNOxzs for ; Tue, 16 Dec 2008 17:59:36 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 0ECA43A68C1 for ; Tue, 16 Dec 2008 17:59:35 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so1599790fga.41 for ; Tue, 16 Dec 2008 17:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=rtggI73SC9wsEWygxOH0Y4dc0+BVU6tHMPX5uTHIeHg=; b=hiGY/s5rMqD2P/xe9ntEkhGjv0Gltz/5fIGhnNKoaAaWfRixyywrB3CC0xnneEjgQP Z/zgZfvcyC8G6f0gkUar23FCREFNWnt2P63tIPvqICstaDkMRnMlhaNsv4diY4r1vBpq QFUW81x7kYiU8wOibphy6FUi/9nlRpDAmJGZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ks5Ot1Z9JAn0UtGiNuZCVnS8YKFBBxQRtkpCqWdYR4Uu/hRFzlQ1CKkGZUW4J23MNc 76vdHPMKjrQiLDtAiyK/tzCWGBh9blp/MMnzu4fnwKc7zpNvBV0wtslNx/f7csAx7KQf MWsj+5bGIf28690wqAVLrk2sTrPMXW9IZozhw= Received: by 10.86.84.18 with SMTP id h18mr117707fgb.22.1229479167042; Tue, 16 Dec 2008 17:59:27 -0800 (PST) Received: by 10.86.70.17 with HTTP; Tue, 16 Dec 2008 17:59:26 -0800 (PST) Message-ID: <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> Date: Tue, 16 Dec 2008 17:59:26 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, This is a more precise mail. Thanks a lot for the effort. > Can we please get answers to these questions -- which in fact > are entirely on topic for the OPsec WG, since they are all > operational security matters ? > > (Single quotes are from me; double-quotes are from Vishwas' > earlier emails.) > > 1: OSPF with Digital Signatures >> >> OSPF with Digital Signatures is an existing mechanism (RFC-2154). >> Is it discussed at the same level of detail as other mechanisms ? No, it is not discussed in the document. The RFC you mention is an Experimental RFC. The draft talks about "Issues with Existing Cryptographic Mechanisms with Routing Protocols". We can discuss the same however (though I would feel it may not exactly fit the draft). > 2: Filtering of IGP packets >>> >>> I have mentioned cases where they may not be able to be filtered. >> >> Which specific cases ? Please provide a URL for your note to the OPsec >> list where you detailed those cases. I have looked, and I can't find >> that note in the OPsec list web archives, terribly sorry. > > This is an immediate operational security issue, if true. > I'm sure I'm not the only person who'd like to understand > the claim more precisely. I have mentioned it in the mail earlier and will mention it again. When an IGP packet is in an ESP packet (even if it is ESP NULL), a middlebox cannot filter the packet, because the middlebox does not know if the packet has been encrypted or not. http://www.ietf.org/mail-archive/web/ipsec/current/thrd5.html is a link to the first page of the discussion. The discussion is a long discussion and http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-00 is a document trying to address the same. > > 3: User interest in SHA mechanisms for IGP authentication >> >> Do you know of anyone other than US DoD that wants this ? >> (US DoD are the only ones that I can identify, and they are >> saying their interest is only for "policy reasons".) >> >> If so, which users ? which RFPs ? We have customers who have asked for the crypto algorithms. I do not think this group is to discuss about particular RFP's. Again let me state it. If you think there are issues with supporting SHA algorithm for IGP's, please mention the issues in the WG where the drafts belongs. Like I have mentioned multiple times, you have been added as an author of one such document youself. > 4: Availability of SHA mechanisms for IGP authentication >> >> Further, there are no known shipping implementations of >> SHA authentication for any IETF-specified IGP. >> (I don't know of any that are even "in progress".) >>> >>> We know of a few including a big router vendor. :)) > > Which ? How many ? When ? > Are they shipping now or in progress now ? We are implementing this and so is Cisco (this has been brought to your notice in private mails earlier but you still bring the issue). The OSPF WG chair(Acee) knows about the other implementaions of the draft by vendors. If we have an implementation report we will get more details then, as I do not have information of all vendors. It sounds interesting that you want to know vendors implementing some solutions because we are writing an issues document with already existing mechanisms. > 5: Claims made by existing IGP authentication documents >>> >>> However if you see most drafts "security considerations" section, >>> they state that using cryptographic authentication is a panicia for all >>> evils. > > I can't find even one RFC or I-D that says anything similar > to "using cryptographic authentication is a panacea for all evils". > > I checked a bunch of documents, which I enumerated in an earlier > email; none contained any such language. > > Which specific document does this ? and on which page ? Please check the drafts in this page http://www.ietf.org/html.charters/ospf-charter.html . As an example see the first draft in the list it states http://www.ietf.org/internet-drafts/draft-ietf-ospf-lls-05.txt Security Considerations The described technique provides the same level of security as OSPFv2 protocol by allowing LLS data to be authenticated using the same cryptographic authentication that OSPFv2 uses (see Section 2.5 for more details). OSPFv3 utilizes IPSec for authentication and encryption [OSPFV3AUTH]. With IPsec, the AH (Authentication Header), ESP (Encapsulating Security Payload), or both are applied to the entire OSPFv3 payload including the LLS block. Our aim is to bring forward the issues with the cryptographic mechanisms. The issues with the cryptographic mechanisms are not stated in the base RFC either and I have mentioned this to you clearly. Because most RFC's draft seem to state something similar to the above. Thanks, Vishwas > Thanks, > Ran > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 16 18:19:44 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E88F3A6A7C; Tue, 16 Dec 2008 18:19:44 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B783A6A7C for ; Tue, 16 Dec 2008 18:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwM9GCAO5LhD for ; Tue, 16 Dec 2008 18:19:43 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id D8DB33A68F9 for ; Tue, 16 Dec 2008 18:19:42 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so1431646ywj.49 for ; Tue, 16 Dec 2008 18:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=S5A+Vs4mGHatAghpJR3ZK+RliO0RmJGfbb/sgX6ra5I=; b=r0FcGazlsgag7K+Zj6cFR8DPSeTlODgiP+++skjR/c37YfddnCoh/h9QRoi8zrvdaq ubnMyjDqiwLm4EfjLbL0LxBjq0sC2UI+rTDOPftZuiwR3ALgJBtqLBSyF4TJPX0luZ0T zscfhMi1pJhmt5ku+MiN+SapH1TBgq4HCCzHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=neCKdh+sGFDz1s/ibRKKqTj9h5F2ZmSpmgt6CauaJre8DVpfkWu8W9bbtzEchLOKO+ mPKEPM/ytRramRxp6g1tM2JMytpczMtq3jPyA6C8zw0SwRG4XV92/Gm3tsOv4hyNN+dh 4G6KNZr0+fE2qybt1i6UuxJuVYdMw97i9//aU= Received: by 10.64.7.12 with SMTP id 12mr145870qbg.36.1229480375106; Tue, 16 Dec 2008 18:19:35 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 28sm402396qbw.16.2008.12.16.18.19.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 18:19:34 -0800 (PST) Message-Id: <69BA9195-6869-45F1-832F-9040901F0C9F@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 16 Dec 2008 21:19:31 -0500 References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 16 Dec 2008, at 20:59, Vishwas Manral wrote: > No, it is not discussed in the document. The RFC you mention is an > Experimental RFC. The draft talks about "Issues with Existing > Cryptographic Mechanisms with Routing Protocols". We can discuss the > same however (though I would feel it may not exactly fit the draft). It would be helpful to discuss also, as that is an IGP authentication mechanism that we have today and that could be used. I'm told that there is at least one implementation, although I'm unclear on how available that implementation might be. > http://www.ietf.org/mail-archive/web/ipsec/current/thrd5.html is a > link to the first page of the discussion. The discussion is a long > discussion Thank you for the URLs. > We have customers who have asked for the crypto algorithms. Other than US DoD ? Very Interesting. Are they Enterprise users ? Service Providers ? other ? Is this for policy reasons or does a particular threat model drive them in that direction ? > We are implementing this and so is Cisco (this has been brought to > your notice in private mails earlier but you still bring the issue). I do not have such any private emails; they must have been lost in transit. Thanks for the clarity. So at least 2 implementations are reported to be in progress, and none are available now. That is useful to understand. > It sounds interesting that you want to know vendors implementing some > solutions because we are writing an issues document with already > existing mechanisms. Your assumption is incorrect. I want to know because the OPsec meeting minutes seemed to suggest that someone proposed this WG should recommend SHA mechanisms over MD5 mechanisms, and I was not aware of any active work to implement any SHA mechanisms. >> 5: Claims made by existing IGP authentication documents >>>> >>>> However if you see most drafts "security considerations" section, >>>> they state that using cryptographic authentication is a panicia >>>> for all >>>> evils. >> >> I can't find even one RFC or I-D that says anything similar >> to "using cryptographic authentication is a panacea for all evils". >> >> I checked a bunch of documents, which I enumerated in an earlier >> email; none contained any such language. >> >> Which specific document does this ? and on which page ? > Please check the drafts in this page > http://www.ietf.org/html.charters/ospf-charter.html . > As an example see the first draft in the list it states > http://www.ietf.org/internet-drafts/draft-ietf-ospf-lls-05.txt > > Security Considerations > > The described technique provides the same level of security as > OSPFv2 > protocol by allowing LLS data to be authenticated using the same > cryptographic authentication that OSPFv2 uses (see Section 2.5 for > more details). > > OSPFv3 utilizes IPSec for authentication and encryption > [OSPFV3AUTH]. > With IPsec, the AH (Authentication Header), ESP (Encapsulating > Security Payload), or both are applied to the entire OSPFv3 payload > including the LLS block. That does not say either that cryptographic authentication is a panacea or that cryptographic authentication is perfect. So the quote does not support your original claim (from the top of Section 5 of my note). The text you quote above simply says that it provides "the same level of security" ... "by using the same cryptographic authentication". The text you quote from that I-D does not even claim that the existing cryptographic authentication is a sufficient level of security. Its claims are really quite narrow and quite mild. > Our aim is to bring forward the issues with the cryptographic > mechanisms. The issues with the cryptographic mechanisms are not > stated in the base RFC either and I have mentioned this to you > clearly. I quoted the base OSPF RFC to this list earlier today, where that RFC indicated that the cryptographic authentication was focused on "passive attack" prevention and showed that that RFC did not claim the cryptographic authentication to be perfect or to be a panacea. So the OSPF RFC does not support your quoted claim either. > Because most RFC's draft seem to state something similar to > the above. The actual IGP authentication RFCs and I-Ds (which I did cite) do not do so. They are what users and implementers read when studying IGP authentication. Further, the "examples" you have cited so far do not support your claim at the top of this section (Section 5 of my email). Thank you for the speedy reply. Yours, Ran Atkinson rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 16 18:37:20 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38B7D3A68F6; Tue, 16 Dec 2008 18:37:20 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95AE3A68F6 for ; Tue, 16 Dec 2008 18:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iA8RQpoXdTv for ; Tue, 16 Dec 2008 18:37:17 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 8A45D3A68AC for ; Tue, 16 Dec 2008 18:37:17 -0800 (PST) Received: by qyk4 with SMTP id 4so3526501qyk.13 for ; Tue, 16 Dec 2008 18:37:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=QTmG2fZE/q4gmBi3kuxBc7+szbcDXCeKxXaPc2Ft/e0=; b=UkFRWj0ZrSEVrYSgWZa/CZnbGSwSDcwRBBUb6SXMoq2Me/b5kv4LqhOrVObjeWmgqU d+d0UdEMUPhJwf+WvdRBWNvr4AJX84MIDISJCzH8aBSLxCVKEiDZYu8QEr23/3IDIt2M zh/vOTXF7rymcrXUnlvE25W/EopWdmmyj/xng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=mwg0Lkz2DaDrDdjjrFazTNLnDDlmGMP69b3VpO+gs4fOgPrwVD0XUSms7PlNvHyM2V 4J/I4cl6o5gKxyrNJWFoIynb6puxtNhz43kTcODNTCOqAwqvv9E8X/OIiFmn1K6ac10r a27eTuUXDV48oKPtNLYb1EwLBZIvITATCVo64= Received: by 10.214.182.6 with SMTP id e6mr183156qaf.239.1229481429527; Tue, 16 Dec 2008 18:37:09 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 5sm5615586ywl.15.2008.12.16.18.37.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 18:37:09 -0800 (PST) Message-Id: <89F12E27-304C-41AD-BC27-556BD9FA7040@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 16 Dec 2008 21:37:07 -0500 References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: [OPSEC] Prospective issue with IPsec ESP-NULL & IGP packets X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 16 Dec 2008, at 20:59, Vishwas Manral wrote: > When an IGP packet is in an ESP packet (even if it is ESP NULL), a > middlebox cannot filter the packet, because the middlebox does not > know if the packet has been encrypted or not. > > http://www.ietf.org/mail-archive/web/ipsec/current/thrd5.html is a > link to the first page of the discussion. The discussion is a long > discussion... (Having now scanned the above thread.) One possible fix would be to deploy AH instead of ESP with NULL encryption. Many firewalls already know how to parse past the AH option and look into the payload. Since AH cannot ever encrypt data, all middleboxes always know that the packet hasn't been encrypted by AH. AH actually provides stronger protections than ESP NULL, as it covers many of the header and IP option fields (which ESP NULL does not do). AH is widely available in shipping router releases today, so using AH is not hard for many router platforms. Most desktop OSs also support AH today, so again it is widely available now and ready for use. In any event, most firewalls today simply drop all IPsec ESP packets. If the ESP packet is tunnel-mode, then the receive-side IPsec implementation is required by the IPsec RFCs to perform various sanity checks before accepting the packet (and potentially forwarding the packet), which checks (properly implemented) should prevent address forgery attacks. If the packet is using transport-mode, then again the IPsec receive-side processing requires various sanity checks that should prevent address forgery attacks. So it seems that if one encounters a buggy IPsec implementation, then one might have buggy results, but that if one does not encounter a buggy IPsec implementation, then there ought not be any issues with forged IGP packets making it inside the administrative domain via IPsec ESP. Of course, with any protocol, if one encounters a buggy implementation, results are not likely to be as desired. Cheers, Ran rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 16 18:46:24 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1533128C0E4; Tue, 16 Dec 2008 18:46:24 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A127728C10F for ; Tue, 16 Dec 2008 18:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSv9jqBJPCeV for ; Tue, 16 Dec 2008 18:46:22 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 2D77128C0DD for ; Tue, 16 Dec 2008 18:46:22 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so1604185fga.41 for ; Tue, 16 Dec 2008 18:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=tywexX8IDPywOYLctcJV8IWzJ6x5sd5wmsZAZAf6RDA=; b=CK/Ec+aUizlrW/WfCHSBkKs1bXf8DcJ2xBkSZaFPOnGKMUqDljhxWt7H/Nfra+qTYW 7ZpswoZJVnkbX2/H0mDEakb9zgtoIscTlTzpLk6dBXT5DirVA4tJa4IpPEmblEKqjndQ JiVDKBNfryXAyNH7M338dZ1S/XY94RTJg4BaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Yt6IlPe3XkVk9CeAAYOsUwd20fT+UgC8w3EzblFPNzEtxV95J49rVtOPwgtIp8FGdx baHIrsmsH+hHQ11j46Sdd920PyB+lcWf1C95kxT+sBtNL3qwBTzpp9tGoMp+BgWu5xit 4cMKX23LAMzbp5cG7AEqt8A182Uv1x/H2eEWc= Received: by 10.86.63.19 with SMTP id l19mr130212fga.40.1229481973559; Tue, 16 Dec 2008 18:46:13 -0800 (PST) Received: by 10.86.70.17 with HTTP; Tue, 16 Dec 2008 18:46:13 -0800 (PST) Message-ID: <77ead0ec0812161846g1cfa399etff00328e1ed79610@mail.gmail.com> Date: Tue, 16 Dec 2008 18:46:13 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <69BA9195-6869-45F1-832F-9040901F0C9F@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> <69BA9195-6869-45F1-832F-9040901F0C9F@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, Thanks that clarifies the first draft atleast in my mind. :) The second draft is about defining the set of algorithms for IGP just like RFC4835 does for IPsec. This is to provide minimal set of cryptographic algorithms to be supported for basic interoperability. With the additional support of new crypto algorithms into IGP's there are now multiple crypto algorithms defined for the same IGP. Also as we move forward and security vulnerabilities are found in cryptographic algorithms, the algorithm support for Routing Protocols can be changed without change of the base protocol RFC's. The issue was seen in IPsec case where we had to move from DES to 3-DES to AES-CCM. Based on the reccomendations of the IETF on various crypto algorithms, we have recommended cryptographic algorithms as MUST- to SHOULD + etc to also give a sense of direction. Thanks, Vishwas On Tue, Dec 16, 2008 at 6:19 PM, R Atkinson wrote: > > On 16 Dec 2008, at 20:59, Vishwas Manral wrote: >> >> No, it is not discussed in the document. The RFC you mention is an >> Experimental RFC. The draft talks about "Issues with Existing >> Cryptographic Mechanisms with Routing Protocols". We can discuss the >> same however (though I would feel it may not exactly fit the draft). > > It would be helpful to discuss also, as that is an IGP authentication > mechanism that we have today and that could be used. I'm told that > there is at least one implementation, although I'm unclear on how > available that implementation might be. > >> http://www.ietf.org/mail-archive/web/ipsec/current/thrd5.html is a >> link to the first page of the discussion. The discussion is a long >> discussion > > Thank you for the URLs. > >> We have customers who have asked for the crypto algorithms. > > Other than US DoD ? Very Interesting. > Are they Enterprise users ? Service Providers ? other ? > > Is this for policy reasons or does a particular threat model > drive them in that direction ? > >> We are implementing this and so is Cisco (this has been brought to >> your notice in private mails earlier but you still bring the issue). > > I do not have such any private emails; they must have been lost in transit. > > Thanks for the clarity. So at least 2 implementations are reported > to be in progress, and none are available now. That is useful to > understand. > >> It sounds interesting that you want to know vendors implementing some >> solutions because we are writing an issues document with already >> existing mechanisms. > > Your assumption is incorrect. > > I want to know because the OPsec meeting minutes seemed to suggest > that someone proposed this WG should recommend SHA mechanisms over > MD5 mechanisms, and I was not aware of any active work to implement > any SHA mechanisms. > >>> 5: Claims made by existing IGP authentication documents >>>>> >>>>> However if you see most drafts "security considerations" section, >>>>> they state that using cryptographic authentication is a panicia for all >>>>> evils. >>> >>> I can't find even one RFC or I-D that says anything similar >>> to "using cryptographic authentication is a panacea for all evils". >>> >>> I checked a bunch of documents, which I enumerated in an earlier >>> email; none contained any such language. >>> >>> Which specific document does this ? and on which page ? >> >> Please check the drafts in this page >> http://www.ietf.org/html.charters/ospf-charter.html . >> As an example see the first draft in the list it states >> http://www.ietf.org/internet-drafts/draft-ietf-ospf-lls-05.txt >> >> Security Considerations >> >> The described technique provides the same level of security as OSPFv2 >> protocol by allowing LLS data to be authenticated using the same >> cryptographic authentication that OSPFv2 uses (see Section 2.5 for >> more details). >> >> OSPFv3 utilizes IPSec for authentication and encryption [OSPFV3AUTH]. >> With IPsec, the AH (Authentication Header), ESP (Encapsulating >> Security Payload), or both are applied to the entire OSPFv3 payload >> including the LLS block. > > That does not say either that cryptographic authentication is a panacea > or that cryptographic authentication is perfect. So the quote does not > support your original claim (from the top of Section 5 of my note). > > The text you quote above simply says that it provides "the same level of > security" ... "by using the same cryptographic authentication". The > text you quote from that I-D does not even claim that the existing > cryptographic authentication is a sufficient level of security. Its > claims are really quite narrow and quite mild. > >> Our aim is to bring forward the issues with the cryptographic >> mechanisms. The issues with the cryptographic mechanisms are not >> stated in the base RFC either and I have mentioned this to you >> clearly. > > I quoted the base OSPF RFC to this list earlier today, where that RFC > indicated that the cryptographic authentication was focused on > "passive attack" prevention and showed that that RFC did not claim the > cryptographic authentication to be perfect or to be a panacea. So the > OSPF RFC does not support your quoted claim either. > >> Because most RFC's draft seem to state something similar to >> the above. > > The actual IGP authentication RFCs and I-Ds (which I did cite) > do not do so. They are what users and implementers read when > studying IGP authentication. > > Further, the "examples" you have cited so far do not support your claim > at the top of this section (Section 5 of my email). > > Thank you for the speedy reply. > > Yours, > > Ran Atkinson > rja@extremenetworks.com > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 16 18:52:09 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADBF33A68F6; Tue, 16 Dec 2008 18:52:09 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E623A68CC for ; Tue, 16 Dec 2008 18:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXgBFQTdJymU for ; Tue, 16 Dec 2008 18:52:08 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 90E463A68AC for ; Tue, 16 Dec 2008 18:52:07 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so1604755fga.41 for ; Tue, 16 Dec 2008 18:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=7K0yunvfjcSDN0kNyH9sBTPiD9aWUe7zmWvxem9ah7w=; b=l5rfKfw5iMWhAGjM2bVu2PptnuVjqhi+DCrqbveNwVh8UqWNSsfNd2jHwGwUlhk2rQ DBv/nSyZigTY84vu/DNN1P7QndWf5nEYopSmUkBu+cM8ccRKjxzbjYgz+oAjssKRIGI2 xX2naYvNJTp4dt09rInaDhzhyn4F6bm9Z5QVg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=TnuFgex/Cgh2Zktp82vz/D/Fz+GTlIPKmne4uGnwFTr3wD4NDtQCrqGRaZrfyz1nkF UmZhuZ0CrQkn8njyIGSB7lv3vo0lkMycAOE1ReS2qHF1iZgY5L6Y8EkLScGcIc/Lc6Qe ZWlUB8610R87WVJHP22/O7gnGql5dqfuEoQ9c= Received: by 10.86.79.19 with SMTP id c19mr133290fgb.41.1229482319378; Tue, 16 Dec 2008 18:51:59 -0800 (PST) Received: by 10.86.70.17 with HTTP; Tue, 16 Dec 2008 18:51:59 -0800 (PST) Message-ID: <77ead0ec0812161851q204bd1e7nd9fc57538d161794@mail.gmail.com> Date: Tue, 16 Dec 2008 18:51:59 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <89F12E27-304C-41AD-BC27-556BD9FA7040@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> <89F12E27-304C-41AD-BC27-556BD9FA7040@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] Prospective issue with IPsec ESP-NULL & IGP packets X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, This is a good point. I brought differences between ESP and AH up in 2005 (check the link below) when the ESP and AH were still not the new RFC's. Note IPsec RFC4301 states AH as a MAY support while ESP is a MUST support. http://www.ietf.org/mail-archive/web/ipsec/current/msg01902.html The idea is that we are trying to move away from AH and ESP support to only ESP support as most of the functionality of AH is sort of already there in ESP, except for the points I mention. I understand it is a noble cause too. Also note that AH is a MAY support for OSPFv3 while ESP is a MUST (just like it is for IPsec). I think the final aim for us needs to be to support one protocol and try to get all the functionality from the same. This is the reason we are trying to make changes to ESP rather than using AH. This discussion however would be better part of the IPsec mailing list then here in my view. Thanks, Vishwas On Tue, Dec 16, 2008 at 6:37 PM, R Atkinson wrote: > > On 16 Dec 2008, at 20:59, Vishwas Manral wrote: >> >> When an IGP packet is in an ESP packet (even if it is ESP NULL), a >> middlebox cannot filter the packet, because the middlebox does not >> know if the packet has been encrypted or not. >> >> http://www.ietf.org/mail-archive/web/ipsec/current/thrd5.html is a >> link to the first page of the discussion. The discussion is a long >> discussion... > > (Having now scanned the above thread.) > > One possible fix would be to deploy AH instead of ESP with NULL > encryption. Many firewalls already know how to parse past the AH > option and look into the payload. Since AH cannot ever encrypt data, > all middleboxes always know that the packet hasn't been encrypted > by AH. AH actually provides stronger protections than ESP NULL, > as it covers many of the header and IP option fields (which ESP > NULL does not do). > > AH is widely available in shipping router releases today, > so using AH is not hard for many router platforms. Most desktop > OSs also support AH today, so again it is widely available > now and ready for use. > > In any event, most firewalls today simply drop all IPsec ESP packets. > > If the ESP packet is tunnel-mode, then the receive-side IPsec > implementation is required by the IPsec RFCs to perform various > sanity checks before accepting the packet (and potentially forwarding > the packet), which checks (properly implemented) should prevent > address forgery attacks. > > If the packet is using transport-mode, then again the IPsec > receive-side processing requires various sanity checks that > should prevent address forgery attacks. > > So it seems that if one encounters a buggy IPsec implementation, > then one might have buggy results, but that if one does not encounter > a buggy IPsec implementation, then there ought not be any issues > with forged IGP packets making it inside the administrative domain > via IPsec ESP. Of course, with any protocol, if one encounters > a buggy implementation, results are not likely to be as desired. > > Cheers, > > Ran > rja@extremenetworks.com > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 07:21:45 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B0E3A6831; Wed, 17 Dec 2008 07:21:45 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FFDB3A6831 for ; Wed, 17 Dec 2008 07:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KN3KnADVkHTY for ; Wed, 17 Dec 2008 07:21:42 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 2BEDA3A6825 for ; Wed, 17 Dec 2008 07:21:41 -0800 (PST) Received: by qyk4 with SMTP id 4so3780490qyk.13 for ; Wed, 17 Dec 2008 07:21:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=gIj9RHLaBwho1xinvzK9CTbV1ZFFcQTs0M+eVqFf57Q=; b=sFIkgnn0ceksTedkVGmIn4cfPjGcY002qhd/CrqUJk4oCUrGZLaLtTg+nivs+5HMCS y3+UDEM9X0mCEhSNiIPe0cYV1smQ8HZ/QWznV/Fv14bAl5IucT/7MHnUlyK6jYRj2DOF oP4qr/kGWtbMvnUJ+6TxocjbkWuGpNXt15e7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=a2l04JgSh3985LMW6oWntX5kWHlNO1e27BBpXX6DTeoGkGUkKz3bgeWUS2EXFww+gw 39+INMnGAoQQqyL5ky8NdxwCY9/rkp/4kr1Igr96oSDLdmBHo5Y7h/M9r6gw/O+UHNbZ tAI0JY+/3Y5HUVJSaM9wZ0tfwQuwziR78J3vU= Received: by 10.214.218.18 with SMTP id q18mr945130qag.115.1229527293925; Wed, 17 Dec 2008 07:21:33 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 6sm2465672ywp.20.2008.12.17.07.21.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Dec 2008 07:21:33 -0800 (PST) Message-Id: <596A619D-6D7B-421E-A43C-47AD1762093F@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812161851q204bd1e7nd9fc57538d161794@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 10:21:31 -0500 References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> <89F12E27-304C-41AD-BC27-556BD9FA7040@gmail.com> <77ead0ec0812161851q204bd1e7nd9fc57538d161794@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] Prospective issue with IPsec ESP-NULL & IGP packets X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 16 Dec 2008, at 21:51, Vishwas Manral wrote: > The idea is that we are trying to move away from AH and ESP support to > only ESP support as most of the functionality of AH is sort of already > there in ESP, except for the points I mention. Hmm. AH provides more comprehensive protections than ESP, in a fundamental way. > Also note that AH is a MAY support for OSPFv3 while > ESP is a MUST (just like it is for IPsec). Most routers already ship with AH, so it is trivial to use AH. > I think the final aim for us needs to be to support one protocol and > try to get all the functionality from the same. This is the reason we > are trying to make changes to ESP rather than using AH. At least some customers have a hard requirement for AH, rather than ESP. It is possible that not all implementers care about those customers. > This discussion however would be better part of the IPsec mailing list > then here in my view. You seem to have missed the main point of my note, which was an Operational Security matter, so I will restate: There is no ESP attack vector that enables an interior node to inject forged IGP packets into a different target domain to subvert the target's IGP routing, provided the user has configured their systems appropriately (e.g. packet filtering at the edges), modulo bugs in their deployed implementations. In the case of implementation bugs, all bets are off anyway, no matter how one configures one's systems or designs one's network. The detailed analysis of why this is NOT actually a problem, even if ESP is in use, was provided in my previous note. Cheers, Ran rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 08:08:37 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307983A6B10; Wed, 17 Dec 2008 08:08:37 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037EA3A6B10 for ; Wed, 17 Dec 2008 08:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWyKDooLAJZB for ; Wed, 17 Dec 2008 08:08:35 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id C1CC53A6B03 for ; Wed, 17 Dec 2008 08:08:34 -0800 (PST) Received: by qyk4 with SMTP id 4so3802297qyk.13 for ; Wed, 17 Dec 2008 08:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=z2VB44K/IcAsBQI6J3h3By/+IxHMuDUyREzd5dpX8QI=; b=HlbqBgB3CdOZlPLPKy+6+WAAfQloLrSHguhRCUUpgGm15cveHW3Cahg18ED+Mdnrh6 waO565PfdmOuolBWK2JHjxLf7jnMiZAy4UqEC6bQuR7jMVLUpyiEswsNIF2Y2ImilD93 6rGn4N2xsvG4gL5bBomgVNP/T7cjVG3H6YAHI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=A6b57yQ/raWvo/6NKeMLqJP1upCyHd6Ul5XBps3vhBLDIURDCNbUOE06O2aDUITw14 CvU/yh71tg4juXoHc+m4lJDp9UW1WYLIeo8UW2opY04uzIkNqWzUfF0AG96e29vNocYt THiaNdgH1+Mz9sdmH920VHIST5SNOrIBLNrnA= Received: by 10.215.66.1 with SMTP id t1mr992871qak.327.1229530106682; Wed, 17 Dec 2008 08:08:26 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 7sm1608250qwf.27.2008.12.17.08.08.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Dec 2008 08:08:26 -0800 (PST) Message-Id: <0D015957-EF5A-4D25-8C1B-410DFE17E46B@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812161846g1cfa399etff00328e1ed79610@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 11:08:24 -0500 References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> <69BA9195-6869-45F1-832F-9040901F0C9F@gmail.com> <77ead0ec0812161846g1cfa399etff00328e1ed79610@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 16 Dec 2008, at 21:46, Vishwas Manral wrote: > The second draft is about defining the set of algorithms for IGP just > like RFC4835 does for IPsec. This is to provide minimal set of > cryptographic algorithms to be supported for basic interoperability. There isn't an actual problem here to be solved. You have reported 2 in-progress implementations of HMAC-SHA for IGP authentication, with 2 being a lot smaller than the set of router families in the world. By contrast, support for Keyed-MD5/HMAC-MD5 is either very widespread or universal. > With the additional support of new crypto algorithms into IGP's there > are now multiple crypto algorithms defined for the same IGP. Also as > we move forward and security vulnerabilities are found in > cryptographic algorithms, the algorithm support for Routing Protocols > can be changed without change of the base protocol RFC's. The existing specs would not need to be changed -- whether or not such a document existed. Your assumption that they would need to be changed is not correct. This is a "Red Herring". > The issue was seen in IPsec case where we had to move from DES to > 3-DES to AES-CCM. IGP authentication is not IPsec; they don't have the same issues. And this is not the OSPF WG or the IS-IS WG, which would be the WGs chartered to make such implementation recommendations for their respective IGPs. > Based on the reccomendations of the IETF on various > crypto algorithms, The IETF has no IETF-wide policy on cryptographic algorithms. According to IETF practice, such decisions are up to each individual WG. > we have recommended cryptographic algorithms as > MUST- to SHOULD + etc to also give a sense of direction. I've cited here several specific scientific papers noting that SHA is just as vulnerable as MD5, which you then agreed was correct. (URLs provided in email from me yesterday) NIST has noted publicly that "serious attacks" have been published against SHA. (URLs were provided yesterday to the NIST web site to support this statement.) I noted earlier that neither Keyed-Hash nor HMAC-Hash have known vulnerabilities, which you also agreed was correct. (OPsec list archives) So one can see that it does not make scientific sense for this WG to recommend anything beyond "some form of cryptographic protection" -- because there is no scientific reason to believe that either approach is better or stronger than the other. Recommending SHA as a "future direction" is particularly silly -- because NIST is in the process of deprecating and replacing the entire current SHA algorithm family due to concerns about its strength. (See the NIST URLs I provided to the WG yesterday) (By the way, the NIST announcement that it would replace SHA was made in 2007. The closing date for proposals to NIST for a new algorithm was October 31st 2008. The new hash algorithm will have different maths, although it might [confusingly, IMHO] be called SHA-3.) If some WG were going to suggest a "future direction" for IGP cryptographic authentication, then an entirely different approach (e.g. some form of AES CBC MAC, such as Rogaway has published) is likely the sensible scientific approach to take, given what is known now. So far as I am aware there is no work in progress on specifying such a thing for any IGP. (Maybe that is an opportunity for someone.) There might be individual users who choose to undergo the pain of migration later from existing approaches (e.g. MD5) to something else (SHA or whatever) for local policy reasons, but that local policy choice is not an IETF matter, and that direction isn't supported by science available to this WG right now. Yours, Ran rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 08:14:34 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01CC23A6B16; Wed, 17 Dec 2008 08:14:34 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B9963A6B16 for ; Wed, 17 Dec 2008 08:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LS-VpVLsbmpv for ; Wed, 17 Dec 2008 08:14:32 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 19B883A683D for ; Wed, 17 Dec 2008 08:14:31 -0800 (PST) Received: by bwz14 with SMTP id 14so5816341bwz.13 for ; Wed, 17 Dec 2008 08:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=vEJCuEdj1aP6SS6DqafweVpv6TQdlxWxszx0BiToQBw=; b=HhnVNNVNEe1wmZ2oU/9eKbaY4mjeI06/M+QpdUkJRJjbJoVaoWNSJV187dC5MxtscN OkDDgx5TsufOVq6TkPurXBRdPqPx5BiYnxEh0YT/VY/7LI0fO1h2aRpPVNuCTmOvexlS K2KV2byPDi2s7knjO+9k5uEPf5zm6uaQSDLhU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=GMVGmubWJIwGBaSUjMiFRxYtHLYiClmHESsh2ESFWYoeJwADyD7yADX1Ou6XLwKRUz 07jbbnBY4bY5873i6toZmcnL8fMgQIB/tjN9b/OiQIIPddALyVkv5EQsAxTHShTej2F5 cm524qlGSeBZtmmYs6VR0loXpoPeazrNaI+pc= Received: by 10.181.10.7 with SMTP id n7mr301730bki.50.1229530463853; Wed, 17 Dec 2008 08:14:23 -0800 (PST) Received: by 10.181.31.13 with HTTP; Wed, 17 Dec 2008 08:14:23 -0800 (PST) Message-ID: <77ead0ec0812170814j3c34ea6aof7df345adfeee56f@mail.gmail.com> Date: Wed, 17 Dec 2008 08:14:23 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <596A619D-6D7B-421E-A43C-47AD1762093F@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> <89F12E27-304C-41AD-BC27-556BD9FA7040@gmail.com> <77ead0ec0812161851q204bd1e7nd9fc57538d161794@mail.gmail.com> <596A619D-6D7B-421E-A43C-47AD1762093F@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] Prospective issue with IPsec ESP-NULL & IGP packets X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, >> The idea is that we are trying to move away from AH and ESP support to >> only ESP support as most of the functionality of AH is sort of already >> there in ESP, except for the points I mention. > > Hmm. AH provides more comprehensive protections than ESP, > in a fundamental way. Are you stating something other than what is in the link I provided. >> Also note that AH is a MAY support for OSPFv3 while >> ESP is a MUST (just like it is for IPsec). > > Most routers already ship with AH, so it is trivial to use AH. Yes, but the aim is to move away from AH. AH has been downgraded to a MAY support in IPsec RFC4301. It is the same for the OSPFv3 RFC too. >> I think the final aim for us needs to be to support one protocol and >> try to get all the functionality from the same. This is the reason we >> are trying to make changes to ESP rather than using AH. > > At least some customers have a hard requirement for AH, > rather than ESP. It is possible that not all implementers > care about those customers. Ok. >> This discussion however would be better part of the IPsec mailing list >> then here in my view. > > You seem to have missed the main point of my note, > which was an Operational Security matter, so I will restate: Thanks for restating it. I am sorry if I missed the point. > There is no ESP attack vector that enables an interior > node to inject forged IGP packets into a different > target domain to subvert the target's IGP routing, > provided the user has configured their systems > appropriately (e.g. packet filtering at the edges), > modulo bugs in their deployed implementations. Ran, the point we were talking is about the packet actually not being able to be filtered by the edge node/ device because the packet is encapsulated in the ESP header. Is there something amiss here - when you say such a packet can be filtered? > In the case of implementation bugs, all bets are off > anyway, no matter how one configures one's systems > or designs one's network. > > The detailed analysis of why this is NOT actually a problem, > even if ESP is in use, was provided in my previous note. > > Cheers, > > Ran > rja@extremenetworks.com > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 08:21:12 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498C03A683D; Wed, 17 Dec 2008 08:21:12 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021243A683D for ; Wed, 17 Dec 2008 08:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-9kBH1uM3r8 for ; Wed, 17 Dec 2008 08:21:10 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 383C03A67FD for ; Wed, 17 Dec 2008 08:21:10 -0800 (PST) Received: by qyk4 with SMTP id 4so3808014qyk.13 for ; Wed, 17 Dec 2008 08:21:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=e5fdxxh/24ZgreAit53SAYVxYahZNBa/UrzCNGHJxVg=; b=hpOT6kbI5p64TvzoYYOzt4FEXQ5ahjUFwGTEj7224146XJrn7QqBglLiu5uom7NevM LTBzeqT6ek7KE7V8RDOA5leMuUfD00xyLuNTFpfWqnKbWmWVwz0nHT45CK70Fqv6bhsj rTujAMoFBKGPSOG7NHbKDMunJR0BsLHqfYFiY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=Va+YPOfP7nMuwE5Xn/LjVAH/t7+vaRoJ3SpL8z/ekpLiNYxgFz8/tZtpqURjPGQB2C Cw5UsAdHcnmL2bWmi+H9B1eSG1ntcIydArHiWRyX/m6SbJwhGx3a3owzd2UuEFYTK7wT kHz/ILzicHJGjPX2wla35L7zkJp05Ey54kNPM= Received: by 10.215.100.9 with SMTP id c9mr1010618qam.356.1229530862149; Wed, 17 Dec 2008 08:21:02 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 7sm10056251qwf.47.2008.12.17.08.21.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Dec 2008 08:21:01 -0800 (PST) Message-Id: From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812170814j3c34ea6aof7df345adfeee56f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 11:21:00 -0500 References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> <89F12E27-304C-41AD-BC27-556BD9FA7040@gmail.com> <77ead0ec0812161851q204bd1e7nd9fc57538d161794@mail.gmail.com> <596A619D-6D7B-421E-A43C-47AD1762093F@gmail.com> <77ead0ec0812170814j3c34ea6aof7df345adfeee56f@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] Prospective issue with IPsec ESP-NULL & IGP packets X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 17 Dec 2008, at 11:14, Vishwas Manral wrote: > Ran, the point we were talking is about the packet actually not being > able to be filtered by the edge node/ device because the packet is > encapsulated in the ESP header. Is there something amiss here - when > you say such a packet can be filtered? Please go re-read my note to OPsec from yesterday for the full analysis. Cheers, Ran _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 17:04:14 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B893A6B56; Wed, 17 Dec 2008 17:04:14 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327443A6B56 for ; Wed, 17 Dec 2008 17:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u07KgGZup7i7 for ; Wed, 17 Dec 2008 17:04:12 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id F33EC3A6B4F for ; Wed, 17 Dec 2008 17:04:11 -0800 (PST) Received: by bwz14 with SMTP id 14so694665bwz.13 for ; Wed, 17 Dec 2008 17:04:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=g6C3+nyGkyccLWqWuxMn5fq1pNzyDcIlTRvq1s0D7eo=; b=OB72D6gtQ2bOTDmDyfIsNzojdgPUwg7w/oePP1s9e/j+ob8Hw3YFgrOY1Ah3iSDg+n 0P4oUog/FrXTI6ZYzOCkEdEAcBIIbprGHFMrF26gFlF80btoLRUVS7pKdcn4vLw6F3sY DUGJnvPVHoTJigZ0fD3j0HvQQnSIv1kFz6yjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Xy7oH/YLYArSktiK2tZTOt1gzJR8lvNARcRl6tWc6sjfCHf85ETafheb231G6DYQyG THutUox4s9hVnaR9jWltP7n3WtSWegoo+N4OYOw1Tz+m9GpYpcKtT+cGNpRt2qvKLN0O zd07rZxdGHs+OCsltttyJ4kQq9ICfr68Pa7I0= Received: by 10.103.189.15 with SMTP id r15mr521248mup.126.1229562242786; Wed, 17 Dec 2008 17:04:02 -0800 (PST) Received: by 10.103.160.12 with HTTP; Wed, 17 Dec 2008 17:04:02 -0800 (PST) Message-ID: <92c950310812171704x76e374bbv1bd74d74f5ca755b@mail.gmail.com> Date: Thu, 18 Dec 2008 06:34:02 +0530 From: "Glen Kent" To: "R Atkinson" In-Reply-To: <12201E12-8A0B-4FBE-95A9-5C8B23DA46EC@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <92c950310812161620j7d8aaa16m553940edadbe6d8f@mail.gmail.com> <12201E12-8A0B-4FBE-95A9-5C8B23DA46EC@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org This does not address the point that i had raised. > I have no concern with the WG documenting any issues, provided: > - they really are technical issues rather than opinion, So, you dont think the issues mentioned in the drafts are technical? OK, how would you categorize those issues? > - the analysis really is comprehensive, including a threat model, > - the analysis also discusses existing mitigations, > and > - the analysis covers all such authentication mechanism, > including for example RFC-2154, not just some of them. Its experimental. Lets leave it out of the discussion. > > (For an individual submission rather than a WG document, of course, > none of the above caveats would apply, as individuals can say > whatever they wish, true or not, in a personal informational RFC. :-) > > As my notes have tried (and perhaps failed, sigh) to make > clear, the focus of my concerns are: > > 1) An apparent proposal, according to the WG minutes, to have > the OPsec WG recommend that users migrate to using SHA-based Can you stop being vague and mention the precise proposal you are arguing against? > mechanisms. There are not solid technical grounds to > recommend/prefer SHA approaches over MD5 approaches > (or the reverse: it isn't obvious that MD5 is better either). So, you dont think there is any value in moving over to SHA based mechanisms, is it? > > 2) Erroneous claims in the meeting minutes that SHA-based approaches > are better than the existing MD5-based mechanisms. The approaches > are very slightly different, but as the URLs I provided much earlier > today make clear, SHA has issues in the published literature just You probably did not notice, but IESG has added a note, in the very RFC (4822) where YOU have added support for SHA for RIP "In the interests of encouraging rapid migration away from Keyed-MD5 and its known weakness, the IESG has approved this document even though it does not meet the guidelines in BCP 107 (RFC 4107)." Glen _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 17:06:43 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3492A3A6B56; Wed, 17 Dec 2008 17:06:43 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D13C3A6B56 for ; Wed, 17 Dec 2008 17:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbUwr9F4Ks-E for ; Wed, 17 Dec 2008 17:06:41 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 579813A66B4 for ; Wed, 17 Dec 2008 17:06:40 -0800 (PST) Received: by bwz14 with SMTP id 14so697164bwz.13 for ; Wed, 17 Dec 2008 17:06:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=hpwdWO+cl+oY80eltFkXV0T2gb9aB1BhzsSBTr62lm0=; b=WSQ4NQnnvzc6Am0GVAzvNX90EYw+NtB4sdU+QNtdsYfZGUbTyCqJ6PCkgWJ+1oTYkK uAMbyFTT9+M/7XerlXQz7VXvIZk/H/5ZBFoOoa3QAeHjPaHBSREJN2P+YHjZV5ZPADDf eODL+oPRJF3aB2uU4x3fUZZdbpXacydxbGGu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jUh89VsBrVIiOGLZ7fhe8SmrvNpSQcjP+SJXBsD+RIfddOQm75qa/4HQvAC0JQc54s ICV72ksH1qwZSVyvuv16aBLraJzNjxbOyADRkdTSCA45fSFhQHW3y9XIAkfa4uzFOgLk PLllTOSQCh5DfqoJOgKJ9n+YlPFJEKn5cqQzo= Received: by 10.103.238.4 with SMTP id p4mr531437mur.68.1229562392517; Wed, 17 Dec 2008 17:06:32 -0800 (PST) Received: by 10.103.160.12 with HTTP; Wed, 17 Dec 2008 17:06:32 -0800 (PST) Message-ID: <92c950310812171706y3902b3edm76bec430f4adf804@mail.gmail.com> Date: Thu, 18 Dec 2008 06:36:32 +0530 From: "Glen Kent" To: "R Atkinson" In-Reply-To: <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org > I object to the assertions in those minutes that: > - the SHA approaches are better/stronger than MD5 approaches. > [We have agreed that the evidence does NOT support such a > claim -- which claim appears to be in the meeting minutes.] > > - the WG should recommend/encourage/promote SHA approaches > over MD5 approaches. [which claim again appears to be > in the meeting minutes] So you're asserting that Md5 is as strong as SHA. Can you please confirm this? Glen _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 17:14:34 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38AF13A6B56; Wed, 17 Dec 2008 17:14:34 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30AB13A6B56 for ; Wed, 17 Dec 2008 17:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwkSKiyndp0x for ; Wed, 17 Dec 2008 17:14:32 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 04A4E3A66B4 for ; Wed, 17 Dec 2008 17:14:31 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so92071fga.41 for ; Wed, 17 Dec 2008 17:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=bxoMl5hoL/pnSskeCygUSMrZtNG1JjnrKKnTS8wpI2U=; b=FxNvrtclwCkPobsYBOyk5tjrszUKL8lolluPgYKhnVtS7T/snEApozz6FaoFT4GiZE Kbb3ol+KklUZNbC7dnT3l9+yLTk7n0hPy6q1FNVJ/NfyK7blbhzfjARQMdEoA9+EJyds vuAJsziiBw7SGLVOmCx8s5Yvfroi1cr7TIN0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=vTGHpsONCc2VjSHzcUlhj1cUWkoYHquYtI0Q3ECBa5iQo33IXr8LQpUTCmymlD0Uyc Rf5JLKAQPvZ+WMTyS9vL0zt7fgehU3f6nvhXnNeKbhcrYMSQvMLXLFYAeL3szE1GY6E4 7BuxWktk7gn48l0aONIrMOq8ivBmYNHE7TQeQ= Received: by 10.103.193.13 with SMTP id v13mr524101mup.125.1229562862941; Wed, 17 Dec 2008 17:14:22 -0800 (PST) Received: by 10.103.160.12 with HTTP; Wed, 17 Dec 2008 17:14:22 -0800 (PST) Message-ID: <92c950310812171714o1576776ax4f0272209ebb26a8@mail.gmail.com> Date: Thu, 18 Dec 2008 06:44:22 +0530 From: "Glen Kent" To: "R Atkinson" In-Reply-To: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org > 1: OSPF with Digital Signatures >> >> OSPF with Digital Signatures is an existing mechanism (RFC-2154). >> Is it discussed at the same level of detail as other mechanisms ? Please stop harping about 2154. Its experimental and you may want to read the Tao of IETF to understand what that means. > > > 2: Filtering of IGP packets >>> >>> I have mentioned cases where they may not be able to be filtered. >> >> Which specific cases ? Please provide a URL for your note to the OPsec >> list where you detailed those cases. I have looked, and I can't find >> that note in the OPsec list web archives, terribly sorry. > > This is an immediate operational security issue, if true. > I'm sure I'm not the only person who'd like to understand > the claim more precisely. I think the context here was IPSec since ESP packets cannot be filtered. > > > 3: User interest in SHA mechanisms for IGP authentication >> >> Do you know of anyone other than US DoD that wants this ? >> (US DoD are the only ones that I can identify, and they are >> saying their interest is only for "policy reasons".) >> >> If so, which users ? which RFPs ? Providers may not be open in accepting this for various policy, political reasons. > > > 4: Availability of SHA mechanisms for IGP authentication >> >> Further, there are no known shipping implementations of >> SHA authentication for any IETF-specified IGP. >> (I don't know of any that are even "in progress".) >>> >>> We know of a few including a big router vendor. :)) > > Which ? How many ? When ? > Are they shipping now or in progress now ? Vendors may not be always willing to share this information. Glen _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 17:16:28 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6843A6B4F; Wed, 17 Dec 2008 17:16:28 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38AA83A6B4F for ; Wed, 17 Dec 2008 17:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Zq5d+5uQWB6 for ; Wed, 17 Dec 2008 17:16:26 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by core3.amsl.com (Postfix) with ESMTP id 497083A66B4 for ; Wed, 17 Dec 2008 17:16:26 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w1so115032mue.9 for ; Wed, 17 Dec 2008 17:16:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=njXMYh+DU7xc+dvSd5gHe57wA/UMEZAeqpFaf4SIHC0=; b=GekjiULk43w94xTYIIXObDLnvKXJxfeOJVtmyXkfPaU+RCDLGTsXB2kGiFkA3Qt59O xvah6woM2lPoWwNzyVbEfCuIXziqWDpinyAH74Sw3aaX/7ZuQd7dKwTBwc0/7JZ8ZJlx qVf4nFOJoDvUt95hFGcQfZpe8fr8mlw++85oI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=QfxeFceB77lFFICixb2pG0BNTR9n+fzM9H4MVT/5Ofv/PvVQqQcYAZyW98n9jnxMqo 6CRNgBJc1gztQmu+8g0wfGmYqQk5xNLx+jUEWlOnfSlm6XItGqPcL+bqO5Fz2tMJq7Tm gWSwgmqwBNeP87PuqxgTUjI37rev98onmRnLg= Received: by 10.103.170.6 with SMTP id x6mr539802muo.13.1229562977254; Wed, 17 Dec 2008 17:16:17 -0800 (PST) Received: by 10.103.160.12 with HTTP; Wed, 17 Dec 2008 17:16:17 -0800 (PST) Message-ID: <92c950310812171716j63bb07d5s2dcbd270fd8173ec@mail.gmail.com> Date: Thu, 18 Dec 2008 06:46:17 +0530 From: "Glen Kent" To: "Vishwas Manral" In-Reply-To: <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> Cc: opsec@ietf.org, R Atkinson Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org >> >> 1: OSPF with Digital Signatures >>> >>> OSPF with Digital Signatures is an existing mechanism (RFC-2154). >>> Is it discussed at the same level of detail as other mechanisms ? > No, it is not discussed in the document. The RFC you mention is an > Experimental RFC. The draft talks about "Issues with Existing > Cryptographic Mechanisms with Routing Protocols". We can discuss the > same however (though I would feel it may not exactly fit the draft). You dont need to - its not required. The draft is about the issues existing in the well known and widely used flavors of authentication as used in the current IGPs. Glen _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 17:18:04 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA4B3A6B4F; Wed, 17 Dec 2008 17:18:04 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4803A694E for ; Wed, 17 Dec 2008 17:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBltE6Ko5qoi for ; Wed, 17 Dec 2008 17:18:02 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.190]) by core3.amsl.com (Postfix) with ESMTP id 6E71A3A66B4 for ; Wed, 17 Dec 2008 17:18:02 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w1so115281mue.9 for ; Wed, 17 Dec 2008 17:17:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=XDKoRGywCfyOBD5V3N/wuSZPww+aunNpVuJmfJRI5DA=; b=QnxtBPqlQVFR2109fIzak13a3Um3PcFro45PT46gHO+Ygrm3JQCZDVpUbnThU7RbKR 3F/4YTXTDJHXZLNejSw5kY/WKb/KFldYVVkDhTDLZQhtVDar3M69A64M0fbd5hUfK9oV Rp8K+40vyNXk7VnDvaeC9oIRWrANDQpvbrwzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=vsguO0T2ds/eUWaJsiAz6lc+VX6QZauFEidUsRNE85TgYyehJAIx7GoLJznNMA1DTT zuRlyZBMDp+I1jTTDUFLXxbgrqyw2Lk3ScA6+zTXhz+BCfiqZwtp+0DMHip5h9w/XaFs +F/3zu85CsVHZXGVnqUBewQ21nLbwCDKcobzQ= Received: by 10.103.24.11 with SMTP id b11mr531787muj.76.1229563073644; Wed, 17 Dec 2008 17:17:53 -0800 (PST) Received: by 10.103.160.12 with HTTP; Wed, 17 Dec 2008 17:17:53 -0800 (PST) Message-ID: <92c950310812171717s437509a4p4d56cf4c697529a@mail.gmail.com> Date: Thu, 18 Dec 2008 06:47:53 +0530 From: "Glen Kent" To: "R Atkinson" In-Reply-To: <69BA9195-6869-45F1-832F-9040901F0C9F@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> <69BA9195-6869-45F1-832F-9040901F0C9F@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org >> >> No, it is not discussed in the document. The RFC you mention is an >> Experimental RFC. The draft talks about "Issues with Existing >> Cryptographic Mechanisms with Routing Protocols". We can discuss the >> same however (though I would feel it may not exactly fit the draft). > > It would be helpful to discuss also, as that is an IGP authentication > mechanism that we have today and that could be used. I'm told that > there is at least one implementation, although I'm unclear on how > available that implementation might be. Is there anyone in this list who is aware of 2154 being deployed. Is there any interest in this WG to include 2154? If none, then this can be safely ignored. Glen _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 17:47:50 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14E03A694D; Wed, 17 Dec 2008 17:47:50 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4E103A68D7 for ; Wed, 17 Dec 2008 17:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVghit4Eoh4c for ; Wed, 17 Dec 2008 17:47:48 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id EF1663A694D for ; Wed, 17 Dec 2008 17:47:47 -0800 (PST) Received: by qyk4 with SMTP id 4so216351qyk.13 for ; Wed, 17 Dec 2008 17:47:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=zrWl2m1+/n21GQEWpClfPe5gi89A14A4//dRu039s2M=; b=ChrVkbKDtoh6xH8vFpVHctHUFcBG2X8UjnoFU1UHBMwWCwJuJ63TGDd5rdHVyfq8bI 3Kmm+oMNsd72tAryn0e6dnTb7oHDMOhO+juP9F4svaroJap/0mzQiHUvbr2yZ4+tIORW NCg0/TXwZfvGjrw6+guv+nsUwFNLFrvl4CHsY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=SxJHXIlNYm3vxKP/1ANa4u5oOon6yedCrNXUaZQhAAuG8EmEtZ8SR+L7MQTMVHmTN1 jRjretAAj+UXxQYZo8h5JiKuBSjwqjRPzITH0vg6UfLGEzkB2dZYHLUDnjp960fL/Lnm j/r23zDOqSekP+aazuGOu1CinzendWd9nGdhw= Received: by 10.214.147.17 with SMTP id u17mr1869403qad.55.1229564859645; Wed, 17 Dec 2008 17:47:39 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 7sm4954235qwb.38.2008.12.17.17.47.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Dec 2008 17:47:39 -0800 (PST) Message-Id: <286BDFBC-58E6-401D-B2DB-90237AB558EA@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <92c950310812171706y3902b3edm76bec430f4adf804@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 20:47:33 -0500 References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <92c950310812171706y3902b3edm76bec430f4adf804@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 17 Dec 2008, at 20:06, Glen Kent wrote: >> I object to the assertions in those minutes that: >> - the SHA approaches are better/stronger than MD5 approaches. >> [We have agreed that the evidence does NOT support such a >> claim -- which claim appears to be in the meeting minutes.] >> >> - the WG should recommend/encourage/promote SHA approaches >> over MD5 approaches. [which claim again appears to be >> in the meeting minutes] > > So you're asserting that Md5 is as strong as SHA. Can you please > confirm this? No. I'm asserting that: At present, there is no data indicating that MD5 (as used for IGP authentication) is either stronger or weaker than SHA (as used for IGP authentication). There was a time (now past) where there were published concerns about the compression function of MD5 [Dobbertin1996] but there were not equivalent concerns about SHA. I cited specific published papers that now indicate strong concerns with the compression function of SHA. I also cited a NIST formal statement indicating that there were "serious attacks" on the compression function of SHA. (In both cases, I provided specific URLs yesterday in email to the OPsec list.) Yours, Ran Atkinson rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 17:55:15 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12D1A3A69F3; Wed, 17 Dec 2008 17:55:15 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A61433A69F3 for ; Wed, 17 Dec 2008 17:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD+k18SdqfUs for ; Wed, 17 Dec 2008 17:55:13 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 7E26D3A69E3 for ; Wed, 17 Dec 2008 17:55:12 -0800 (PST) Received: by bwz14 with SMTP id 14so743932bwz.13 for ; Wed, 17 Dec 2008 17:55:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=6rXLeJmEwaZciVTaGziwHzWhJhGpmTKYpNEutdo47l4=; b=BbA202vKqlQsrnJ9Z4E/LWbxQu2x5Hh9aEugjeN+n6CXcFvq4mU38yVMww/xY+Yn3o uAJgr0RP+4ShW5ed1AYfO4LoTP1mNvhmnUUcuPluilQttD7MQVOWGjpMnwSEp6DkeU6d j8HSBpLgMVramOEYAGe6AySXjAnfzoKDkG2bo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=O0Q7BF4S0ddU/Qx5Pn/Yb6ZH7IcnELk2KFnD8OjrUOMvkzArWeAn7QSUm5nOwPIoHF Ofe5Eqx7V0IzsIidVUyB2FukY3BCPLi8DVG/Eiu1skKIRxrvWlj/5I+WA7CXqGQ9r/4U KQAZDThz3qLaMJGCuyf8m6P8jNQleFknjXRBw= Received: by 10.181.18.2 with SMTP id v2mr458277bki.194.1229565303184; Wed, 17 Dec 2008 17:55:03 -0800 (PST) Received: by 10.181.31.13 with HTTP; Wed, 17 Dec 2008 17:55:03 -0800 (PST) Message-ID: <77ead0ec0812171755h4512ce7dvf5f02205015c9111@mail.gmail.com> Date: Wed, 17 Dec 2008 17:55:03 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <286BDFBC-58E6-401D-B2DB-90237AB558EA@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <92c950310812171706y3902b3edm76bec430f4adf804@mail.gmail.com> <286BDFBC-58E6-401D-B2DB-90237AB558EA@gmail.com> Cc: opsec wg mailing list Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran/ Glen, Let me get back on this to you on this one. Thanks, Vishwas On Wed, Dec 17, 2008 at 5:47 PM, R Atkinson wrote: > > On 17 Dec 2008, at 20:06, Glen Kent wrote: >>> >>> I object to the assertions in those minutes that: >>> - the SHA approaches are better/stronger than MD5 approaches. >>> [We have agreed that the evidence does NOT support such a >>> claim -- which claim appears to be in the meeting minutes.] >>> >>> - the WG should recommend/encourage/promote SHA approaches >>> over MD5 approaches. [which claim again appears to be >>> in the meeting minutes] >> >> So you're asserting that Md5 is as strong as SHA. Can you please confirm >> this? > > No. I'm asserting that: > > At present, there is no data indicating that MD5 > (as used for IGP authentication) is either stronger > or weaker than SHA (as used for IGP authentication). > > > There was a time (now past) where there were published > concerns about the compression function of MD5 > [Dobbertin1996] but there were not equivalent concerns > about SHA. I cited specific published papers that now > indicate strong concerns with the compression function > of SHA. I also cited a NIST formal statement indicating > that there were "serious attacks" on the compression > function of SHA. (In both cases, I provided specific > URLs yesterday in email to the OPsec list.) > > Yours, > > Ran Atkinson > rja@extremenetworks.com > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 17:56:59 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CFC53A6A24; Wed, 17 Dec 2008 17:56:59 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597493A69F3 for ; Wed, 17 Dec 2008 17:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAMjFV6-fpoT for ; Wed, 17 Dec 2008 17:56:57 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 4E5BD3A69E3 for ; Wed, 17 Dec 2008 17:56:57 -0800 (PST) Received: by qyk4 with SMTP id 4so219723qyk.13 for ; Wed, 17 Dec 2008 17:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=EqcqbfmzRlESA+FJAAngz1hawKi7G8QnZMumAoD5W9c=; b=DFE3HB2BGu08S/391KiNB4PIhRrDZI93fvXt7+r3J/yih1QCGndqMEdYhpef4PZoe+ a+8Ncwmkj9uqwrKgtoBSrKOaFE1ZZQ7+ecjwAVebHUUtYVnO6R9sAHtSuC0uoBrpqxW5 ljTBFcdKl37Ew7giYOdN/kjq82BMRLgJBtOrI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=xNr0p8WLNjx7km5Ev0DjTc8SLOKjNbjoXOQgnqaMaGYwVs/9jzT4KgkEgm/noazvGX JQmOKfCn/9+HIFNYpWW6OsADEeTTbi0u309M5A0H+PoE7x89u2r+T2PEO51DJhckVnH5 CVLSoPDNdxiZanoX6KUVo/Ib7nBVOANf/koRM= Received: by 10.214.115.16 with SMTP id n16mr1865569qac.104.1229565408708; Wed, 17 Dec 2008 17:56:48 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 6sm4560319ywn.6.2008.12.17.17.56.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Dec 2008 17:56:48 -0800 (PST) Message-Id: From: R Atkinson To: opsec@ietf.org In-Reply-To: <92c950310812171704x76e374bbv1bd74d74f5ca755b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 20:56:46 -0500 References: <92c950310812161620j7d8aaa16m553940edadbe6d8f@mail.gmail.com> <12201E12-8A0B-4FBE-95A9-5C8B23DA46EC@gmail.com> <92c950310812171704x76e374bbv1bd74d74f5ca755b@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 17 Dec 2008, at 20:04, Glen Kent wrote: > This does not address the point that i had raised. > >> I have no concern with the WG documenting any issues, provided: >> - they really are technical issues rather than opinion, > > So, you dont think the issues mentioned in the drafts are technical? > OK, how would you categorize those issues? Let me repeat: My comments here have been focused on the comments reported *meeting minutes*. I have made no assertions about any drafts. >> - the analysis really is comprehensive, including a threat model, >> - the analysis also discusses existing mitigations, >> and >> - the analysis covers all such authentication mechanism, >> including for example RFC-2154, not just some of them. > > Its experimental. Lets leave it out of the discussion. It is real and it is (IMHO) a whole lot better than anything else we have -- and I understand at least one implementation exists. So we should include it in the discussion. >> (For an individual submission rather than a WG document, of course, >> none of the above caveats would apply, as individuals can say >> whatever they wish, true or not, in a personal informational RFC. :-) >> >> As my notes have tried (and perhaps failed, sigh) to make >> clear, the focus of my concerns are: >> >> 1) An apparent proposal, according to the WG minutes, to have >> the OPsec WG recommend that users migrate to using SHA-based > > Can you stop being vague and mention the precise proposal you are > arguing against? Kindly see the meeting minutes, which is what ALL of my comments have been reacting to. >> mechanisms. There are not solid technical grounds to >> recommend/prefer SHA approaches over MD5 approaches >> (or the reverse: it isn't obvious that MD5 is better either). > > So, you dont think there is any value in moving over to SHA based > mechanisms, is it? At present, there is no known scientific data indicating that SHA-based approaches are either stronger or weaker than MD5-based approaches **as used in the current IGP authentication specifications**. If you know of a published paper that explains that either one is stronger **as used for IGP authentication**, for example when used in the same cryptographic modes as for IGP authentication, then please share the document (or a URL/formal citation to it) so everyone can read it. > You probably did not notice, but IESG has added a note, in the very > RFC (4822) where YOU have added support for SHA for RIP > > "In the interests of encouraging rapid migration away from Keyed-MD5 > and its known weakness, the IESG has approved this document even > though it does not meet the guidelines in BCP 107 (RFC 4107)." I'm aware of that. Look at the date on RFC-4822: February 2007 AFTER that IESG statement, in *November 2007*, NIST posted its formal notice (URL provided previously) that SHA now has "serious attacks" and that NIST was soliciting a replacement algorithm -- so that NIST can replace/deprecate the current SHA algorithm. BOTTOM LINE: The prior confidence in SHA's compression function doesn't exist NOW due to publication of papers describing "serious attacks" (quote from NIST) on SHA's compression function. Yours, Ran rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 17:58:31 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BEF83A6A24; Wed, 17 Dec 2008 17:58:31 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750223A6A24 for ; Wed, 17 Dec 2008 17:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGPCx0q5YpAx for ; Wed, 17 Dec 2008 17:58:29 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id B41CC3A69F3 for ; Wed, 17 Dec 2008 17:58:29 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so49206qwe.31 for ; Wed, 17 Dec 2008 17:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=MRq6iqLwiwlYz53Ka2dr1a0TGmO5l7zCwlxIwG8jKFg=; b=vroerxwLP5QNQ4hlxci4EsTtdgnKUa0EWIzEKdaliLJzOWFm2QQ++bvm4jgjTNG4CU EUJ/wzF8APiZoZA9Am+7umtK3Bf+/QR9f/p+adIiZDoZZp9n/fooJdtqE5Au6DKHkIUU NZSQKnmxM5BoKXK2kPMY3uaOUE1rjXtFDRxU0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=n4epwMVFFnVQMb+JB9D510CANeBeGiUqGm2RNu+Si1AqjmT0WIX1TuQ8/GhsuAxA+J 9cYAxghV7Y/GaTfjCLd2g0IGoFopF3+nXm9wwpbD8b3hyn9+44/AXC9mNkAHHDcje871 M7qmnMP1zkmnQ4s7cotpioJhyKlu/Y+CYWxWE= Received: by 10.214.113.11 with SMTP id l11mr1850716qac.190.1229565500891; Wed, 17 Dec 2008 17:58:20 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 9sm1184975yws.51.2008.12.17.17.58.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Dec 2008 17:58:20 -0800 (PST) Message-Id: <579EBECB-1589-4A9D-AD70-5BB247612DA7@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <92c950310812171717s437509a4p4d56cf4c697529a@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 20:58:18 -0500 References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> <69BA9195-6869-45F1-832F-9040901F0C9F@gmail.com> <92c950310812171717s437509a4p4d56cf4c697529a@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 17 Dec 2008, at 20:17, Glen Kent wrote: > Is there anyone in this list who is aware of 2154 being deployed. Yes, within the US Government. > Is there any interest in this WG to include 2154? Yes. Good questions. Yours, Ran Atkinson rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 18:00:07 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4E23A69F3; Wed, 17 Dec 2008 18:00:07 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A4743A6A24 for ; Wed, 17 Dec 2008 18:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQDRoJY+XBJ7 for ; Wed, 17 Dec 2008 18:00:05 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id B69B73A69E3 for ; Wed, 17 Dec 2008 18:00:05 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so49310qwe.31 for ; Wed, 17 Dec 2008 17:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=8Wg9CTa/ko1t88pYPm4UUWfnyiqACZJf+jq8iMblHzs=; b=OrjfXXbPEuk+U/LqcJ25EeV/WHF57I4IG36+l6VvUUtJ3lZ1gwRv4b3ro/lmCHxXK1 +jWpubBHtKnugo+y+CnPZzMjw/cdIWv0lA2VoNoGARAv5BIm6+FAyMyX1OgmOOrw9VCW TP9RNZFC9UXlCs0+748H48AsV9HkQ5h28SDW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=MJDimR57E7aM/DRVklwENPJ9BAROrqo7sKQobxry/q5EUfzev7RybZv1Ih6ChDa97H brLcdvvibsROnD8/8DPHPEMWJUpfdi/Se/GG2kbUve9S4WCTnnz3aRFy/arWicHPeQRa eoscv1IXNwtD8QcOJeDoqgVQ6iCpvfR9YbEHw= Received: by 10.214.181.20 with SMTP id d20mr1819690qaf.378.1229565596994; Wed, 17 Dec 2008 17:59:56 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 6sm4566636ywn.6.2008.12.17.17.59.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Dec 2008 17:59:56 -0800 (PST) Message-Id: <6A3E6D7A-6475-4B5D-B3A9-F865D3133736@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <92c950310812171716j63bb07d5s2dcbd270fd8173ec@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 20:59:55 -0500 References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> <92c950310812171716j63bb07d5s2dcbd270fd8173ec@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 17 Dec 2008, at 20:16, Glen Kent wrote: >> No, it is not discussed in the document. The RFC you mention is an >> Experimental RFC. The draft talks about "Issues with Existing >> Cryptographic Mechanisms with Routing Protocols". We can discuss the >> same however (though I would feel it may not exactly fit the draft). > > You dont need to - its not required. You are formally declaring WG consensus ? Curious. Or were you expressing your opinion ? > The draft is about the issues existing in the well known and widely > used flavors of authentication as used in the current IGPs. If the draft is a WG document, then the WG as a whole needs to decide that question -- while following IETF processes. Yours, Ran Atkinson rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 18:03:06 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 089EA3A695F; Wed, 17 Dec 2008 18:03:06 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804023A695F for ; Wed, 17 Dec 2008 18:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zmWY7uOZx+C for ; Wed, 17 Dec 2008 18:03:04 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 997563A6959 for ; Wed, 17 Dec 2008 18:03:04 -0800 (PST) Received: by qyk4 with SMTP id 4so221765qyk.13 for ; Wed, 17 Dec 2008 18:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=EbDD4olw3LRQ8qZqPYfgtKxx6/kdpRX+k75na6T7mlM=; b=WqpVSGEGC9iibD+MySXbcAuRfFtV+AVqdTwo+S94o+BK1b0DSujmNT5SHEN6/S9P4X u9pY/QfjFXMGzAxL4KoufmqEaLwN+NdAVOBCKki22zfLN7rBUD12wS5+M9+m+/gxcutp 6ljmpiycPqP1vcqP8wibZxXPnpR1IYclaSZzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=RuO3vyKMU7v8wVrwfYLzbGJsZ4xNii2QdT9psjtw07tWu+GxWiAO1u+Vh1AataGfVH B02XmM2MqprydcoNjpNQIv28FfyXOojz/mFe5ZYQBsy1JCA1z+snH0/LIpj88YUY3qHm sS/2QLdOZ1tG/8PJZeKiU8wMsKeH/Lr795YA8= Received: by 10.215.41.6 with SMTP id t6mr1853616qaj.183.1229565776859; Wed, 17 Dec 2008 18:02:56 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 6sm4045059ywi.14.2008.12.17.18.02.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Dec 2008 18:02:56 -0800 (PST) Message-Id: <2A6983D6-439F-4480-85E9-571321C26B31@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <92c950310812171714o1576776ax4f0272209ebb26a8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 21:02:54 -0500 References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <92c950310812171714o1576776ax4f0272209ebb26a8@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 17 Dec 2008, at 20:14, Glen Kent wrote: >> 2: Filtering of IGP packets >>>> >>>> I have mentioned cases where they may not be able to be filtered. >>> >>> Which specific cases ? Please provide a URL for your note to the >>> OPsec >>> list where you detailed those cases. I have looked, and I can't find >>> that note in the OPsec list web archives, terribly sorry. >> >> This is an immediate operational security issue, if true. >> I'm sure I'm not the only person who'd like to understand >> the claim more precisely. > > I think the context here was IPSec since ESP packets cannot be > filtered. My note yesterday tried to explain why if IPsec is implemented according to the RFCs, then there isn't actually an IGP vulnerability to forged IGP packets from outside the routing domain due to IPsec ESP. If you think my analysis posted yesterday was incorrect, which is always possible, kindly educate me. :-) Cheers, Ran rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 19:19:38 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258233A6B6A; Wed, 17 Dec 2008 19:19:38 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC8C63A6B6A for ; Wed, 17 Dec 2008 19:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOy+FfWMscuR for ; Wed, 17 Dec 2008 19:19:36 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 8995C3A68AB for ; Wed, 17 Dec 2008 19:19:35 -0800 (PST) Received: by bwz14 with SMTP id 14so823408bwz.13 for ; Wed, 17 Dec 2008 19:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=sJYcrfNIqUVIEaquFFxKlIIHdiZrtiJIBITfGOFiaWE=; b=uyvL/0pc8DO/a/ni0e0T0OVAdPNQiCE5eKnNGGvrP55EYdIsRltFB5NVcC3VaY0cHV A9E5j8tuBkWMH8Xtjuuq8WZ+aJ+SK7Tc4IO8sdIF/SpCW3PRY8cxL9nvsPidBf7kWdK5 xZlyj+elyE0YHC3wWFFUQ1h/YmZMsqNHCu9to= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=wrlYU+uIrxoyyIlAyii+JIOX79CuPVsFux0gv/c1QuYlciG/bRg2u16J149HZgg9bA lYaDXyJJSO/6p4qEwFwRRck8uoD+vUVaKU41IYJmfbOEKJ/PhjgVaY+9dfd3fjd/0ZLm WO7ktcBNuoyXRw4wiOFKFQuWWATemqv3nCSpc= Received: by 10.181.158.3 with SMTP id k3mr483990bko.182.1229570366550; Wed, 17 Dec 2008 19:19:26 -0800 (PST) Received: by 10.181.31.13 with HTTP; Wed, 17 Dec 2008 19:19:26 -0800 (PST) Message-ID: <77ead0ec0812171919t5c160a2fl423805c8ad0941c3@mail.gmail.com> Date: Wed, 17 Dec 2008 19:19:26 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> <89F12E27-304C-41AD-BC27-556BD9FA7040@gmail.com> <77ead0ec0812161851q204bd1e7nd9fc57538d161794@mail.gmail.com> <596A619D-6D7B-421E-A43C-47AD1762093F@gmail.com> <77ead0ec0812170814j3c34ea6aof7df345adfeee56f@mail.gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] Prospective issue with IPsec ESP-NULL & IGP packets X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, As you have sent so many mails with so much text would it be possible for you to point out which mail I should read. I am unable to understand how you can say ESP packets can be filtered at the edge based on the content. That is a problem IPsecme is trying to solve. Thanks, Vishwas On Wed, Dec 17, 2008 at 8:21 AM, R Atkinson wrote: > > On 17 Dec 2008, at 11:14, Vishwas Manral wrote: >> >> Ran, the point we were talking is about the packet actually not being >> able to be filtered by the edge node/ device because the packet is >> encapsulated in the ESP header. Is there something amiss here - when >> you say such a packet can be filtered? > > Please go re-read my note to OPsec from yesterday > for the full analysis. > > Cheers, > > Ran > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 19:34:49 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F793A68AB; Wed, 17 Dec 2008 19:34:49 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502083A67D6 for ; Wed, 17 Dec 2008 19:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pB2KsgNoWLN8 for ; Wed, 17 Dec 2008 19:34:46 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id BEC923A6835 for ; Wed, 17 Dec 2008 19:34:45 -0800 (PST) Received: by bwz14 with SMTP id 14so837040bwz.13 for ; Wed, 17 Dec 2008 19:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=SRyDJGe9VjTdSTHpVH/I2SZ4PyhCSjNpfOTA9GPk8ME=; b=nuv2daY3kZhKCZ2K0OCBIW7CJiog6iRLMDUr0rbWRQSBbGRZKcfhrqewzVbysuUc4K aF63bq19B22iGnThCpFOQFUr9wHZD9LLgHJgshPMeucw8EPGWazw1CbrhNgH8GSklL5E 9Olb4UPQk6Lrf1UX6N/Xrf7OhIU/8X8xlIW/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=LnWkyGpux1w0dtuDDPZpK2qeyAni0pJSap16LwaMvomFONn8W3Q5srBsbvFBMHuh/k RDeZQupIxySqJFEbHx9os1X1+KEqxAw9jbCa9TgswtYbixIxF5h9bfddj40xZ7nQ5JxJ 3om97WAy4aEQDa/giZB41GOpEmd3gOhYrVhfQ= Received: by 10.181.235.14 with SMTP id m14mr498325bkr.28.1229571276298; Wed, 17 Dec 2008 19:34:36 -0800 (PST) Received: by 10.181.31.13 with HTTP; Wed, 17 Dec 2008 19:34:36 -0800 (PST) Message-ID: <77ead0ec0812171934h6aa29070p9b3d471e64dc4916@mail.gmail.com> Date: Wed, 17 Dec 2008 19:34:36 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <0D015957-EF5A-4D25-8C1B-410DFE17E46B@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> <69BA9195-6869-45F1-832F-9040901F0C9F@gmail.com> <77ead0ec0812161846g1cfa399etff00328e1ed79610@mail.gmail.com> <0D015957-EF5A-4D25-8C1B-410DFE17E46B@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, >> The second draft is about defining the set of algorithms for IGP just >> like RFC4835 does for IPsec. This is to provide minimal set of >> cryptographic algorithms to be supported for basic interoperability. > > There isn't an actual problem here to be solved. There are multiple crypto algorithms that have been defined, there is a need to define a minimal set to support to achieve minimal interoperability. As all IGP's and possibly other protocols like BGP have similar requirements from their cryptographic algorithms, we have made a generic document which can talk about the crypto requirements of all routing protocols. If you do not see the need for it, please do not claim there is no problem. Please state you are unable to see the problem. > You have reported 2 in-progress implementations of HMAC-SHA > for IGP authentication, with 2 being a lot smaller than the > set of router families in the world. > > By contrast, support for Keyed-MD5/HMAC-MD5 is either > very widespread or universal. Can you let me know any OSPF implementation which support HMAC-MD5 please? >> With the additional support of new crypto algorithms into IGP's there >> are now multiple crypto algorithms defined for the same IGP. Also as >> we move forward and security vulnerabilities are found in >> cryptographic algorithms, the algorithm support for Routing Protocols >> can be changed without change of the base protocol RFC's. > > The existing specs would not need to be changed -- whether or not > such a document existed. Your assumption that they would > need to be changed is not correct. This is a "Red Herring". You did not understand what I meant, but let me restate. If there are multiple algorithms to support interoperability if some algorithms are made a MUST/ SHOULD support in the protocol itself it may require changes. We have worked and fixed the same issue in IPsec. We do not want to go through and have the same issues again before we change things in IGP's. I cannot take an argument of waiting to see things fail before taking action, which is exactly what you seem to suggest in all your mails. We have had the issue in IPsec nad have solved it, we are learning from that and improving things in other places too. >> The issue was seen in IPsec case where we had to move from DES to >> 3-DES to AES-CCM. > > IGP authentication is not IPsec; they don't have the same > issues. > > And this is not the OSPF WG or the IS-IS WG, which would be > the WGs chartered to make such implementation recommendations > for their respective IGPs. Yes, this has been discussed with the Routing AD's and the chair of the OSPF WG (and probably the IS-IS WG too). If you have issues about the location please raise it in the right forum. >> Based on the reccomendations of the IETF on various >> crypto algorithms, > > The IETF has no IETF-wide policy on cryptographic algorithms. > According to IETF practice, such decisions are up to each > individual WG. Yes and the Routing AD's have based on the current state decided to bring the work to OPSEC. >> we have recommended cryptographic algorithms as >> MUST- to SHOULD + etc to also give a sense of direction. > > I've cited here several specific scientific papers noting that > SHA is just as vulnerable as MD5, which you then agreed > was correct. (URLs provided in email from me yesterday) As I have said I prefer focussed mails. I have said atleast 4 times now that if you have issues with defining SHA algorithm for protocols please raise it in the right forum. I have told you multiple times which forum the discussion is relevent for. Thanks, Vishwas > NIST has noted publicly that "serious attacks" have been > published against SHA. (URLs were provided yesterday > to the NIST web site to support this statement.) > > I noted earlier that neither Keyed-Hash nor HMAC-Hash > have known vulnerabilities, which you also agreed > was correct. (OPsec list archives) > > So one can see that it does not make scientific sense > for this WG to recommend anything beyond "some form of > cryptographic protection" -- because there is no scientific > reason to believe that either approach is better or > stronger than the other. > > Recommending SHA as a "future direction" is particularly > silly -- because NIST is in the process of deprecating > and replacing the entire current SHA algorithm family > due to concerns about its strength. (See the NIST URLs > I provided to the WG yesterday) > > (By the way, the NIST announcement that it would replace > SHA was made in 2007. The closing date for proposals to > NIST for a new algorithm was October 31st 2008. The new > hash algorithm will have different maths, although it might > [confusingly, IMHO] be called SHA-3.) > > If some WG were going to suggest a "future direction" > for IGP cryptographic authentication, then an entirely > different approach (e.g. some form of AES CBC MAC, > such as Rogaway has published) is likely the sensible > scientific approach to take, given what is known now. > > So far as I am aware there is no work in progress on > specifying such a thing for any IGP. (Maybe that is > an opportunity for someone.) > > There might be individual users who choose to undergo the > pain of migration later from existing approaches (e.g. MD5) > to something else (SHA or whatever) for local policy reasons, > but that local policy choice is not an IETF matter, > and that direction isn't supported by science available > to this WG right now. > > Yours, > > Ran > rja@extremenetworks.com > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 20:39:43 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36CC13A689F; Wed, 17 Dec 2008 20:39:43 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391F93A689F for ; Wed, 17 Dec 2008 20:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aSeaISWbHWr for ; Wed, 17 Dec 2008 20:39:41 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id EB67E3A65A5 for ; Wed, 17 Dec 2008 20:39:40 -0800 (PST) Received: by qyk4 with SMTP id 4so271691qyk.13 for ; Wed, 17 Dec 2008 20:39:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=ivUkV6fgVrD1N/xm9CXCj7oWCWFcB0Jr2grIEcXXK30=; b=woO6sPS4Sd7cdhVxgGJYHyEej45Oco4v/tPbZz+kbCNXic5OjDvmiVeVWV565nmnJs FSnnBpRjS7X4ZV2Kakfvs5XDke/KEpZp23Y8/lfAF4VnWFYeUMrHo3e72wcsWADnT0vk zNt4Izgr+xUlMjOxc5aJ3R58YWHktisZFJimE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=rxZmiggWryCDCx1SH3dtFuwroNZXhIdEJ7JVWLN5JprGkdZPcCZECr72C1nxFNP7tw xzLT8wHSVPu/8n4ZSb9yRLYlwUJMnLNTpcQ9jNR+2hro7CWp7uFvqFWCHZIOKk4AGrKo 83bcxkUpRt4aV8UIQLG9DHCHif2hqzpWHhrq4= Received: by 10.214.215.3 with SMTP id n3mr1922807qag.243.1229574829193; Wed, 17 Dec 2008 20:33:49 -0800 (PST) Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 5sm18549141ywl.55.2008.12.17.20.33.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Dec 2008 20:33:48 -0800 (PST) Message-Id: <50306CFE-EB0E-4AB7-8493-44778B6A5B7F@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812171934h6aa29070p9b3d471e64dc4916@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 23:33:46 -0500 References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> <69BA9195-6869-45F1-832F-9040901F0C9F@gmail.com> <77ead0ec0812161846g1cfa399etff00328e1ed79610@mail.gmail.com> <0D015957-EF5A-4D25-8C1B-410DFE17E46B@gmail.com> <77ead0ec0812171934h6aa29070p9b3d471e64dc4916@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 17 Dec 2008, at 22:34, Vishwas Manral wrote: >> By contrast, support for Keyed-MD5/HMAC-MD5 is either >> very widespread or universal. > Can you let me know any OSPF implementation which support HMAC-MD5 > please? Which part of "Keyed-MD5/HMAC-MD5" was confusing ? > You did not understand what I meant, but let me restate. I understand what you are saying. You believe there is a problem. After considering your explanations, I disagree that there is an actual problem here. >>> we have recommended cryptographic algorithms as >>> MUST- to SHOULD + etc to also give a sense of direction. >> >> I've cited here several specific scientific papers noting that >> SHA is just as vulnerable as MD5, which you then agreed >> was correct. (URLs provided in email from me yesterday) > As I have said I prefer focussed mails. I have said atleast 4 times > now that if you have issues with defining SHA algorithm for protocols > please raise it in the right forum. I have told you multiple times > which forum the discussion is relevent for. Somehow I must not have been clear, despite repeated attempts; I'm terribly sorry. **The issue is NOT -- and NEVER has been -- whether any particular algorithm (e.g. SHA) is defined for use with any particular IGP.** (Please drop that mis-conception.) BACKGROUND: - There is agreement, including from you yesterday to the OPsec list, that there are now serious concerns with the SHA algorithm. [1][2] - There is agreement, including from you yesterday to the OPsec list, that there are serious concerns with the MD5 algorithm. [Dobbertin1996] - There is agreement, including from you yesterday to the OPsec list, that there are no known attacks on any of the IGP cryptographic authentication approaches (Keyed-Hash or HMAC-Hash). - NIST announced "serious attacks" on SHA in November 2007.[2] NIST has also announced that they are working actively to develop replacements for the current SHA algorithms because of those attacks. KEY POINT: The WG has no scientific basis right now to recommend SHA as a future direction over MD5. Note also that the WG doesn't have a scientific basis to suggest that the MD5 approaches are cryptographically better than the SHA approaches. Right now, the published peer-reviewed literature indicates that *both* SHA and MD5 have serious issues with their compression functions. SECONDARY POINT: Some other cryptographic hash algorithm might be a better choice than either SHA and MD5. For example, Phil Rogaway has published papers on an AES-based CBC MAC algorithm. [http://www.cs.ucdavis.edu/~rogaway/papers/xcbc.pdf] (CAVEAT: I don't know if that particular algorithm is a good choice or not. It is simply an *example* of an algorithm that is different than either MD5 or SHA. One imagines that a range of alternative algorithms exist. I think Rogaway's algorithm is the basis for RFC-3566.) OTHER: The facts available to us now are *different* than the facts of several years ago. We know things now that we could not have known BEFORE the widespread publication of attacks on SHA AND could not have known BEFORE NIST's public statement last November that NIST is working actively to develop a replacement for the current SHA algorithm. If someone can find a peer-reviewed publication performing a scientific analysis comparing the SHA and MD5 algorithms **with the cryptographic modes used in IGP authentication**, then the WG might have a scientific basis to recommend one or more approaches over other approaches. Either a full bibliographic citation or a URL to such a peer-reviewed paper would be most helpful, because the WG could then read that paper, and (if appropriate) cite that paper as the basis for whatever WG recommendation(s) might arise from that paper. Right now, there simply isn't enough scientific data to recommend any one approach over another -- among the set of extant IGP cryptographic authentication approaches. Any recommendation(s) made by an IETF WG should be made on a scientific basis, IMHO. Yours, Ran rja@extremenetworks.com URLs repeated from yesterday for convenience: [1] [2] _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Dec 17 20:40:35 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A77D3A689F; Wed, 17 Dec 2008 20:40:35 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1103A689F for ; Wed, 17 Dec 2008 20:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fyzSpu7410P for ; Wed, 17 Dec 2008 20:40:32 -0800 (PST) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 5F4823A65A5 for ; Wed, 17 Dec 2008 20:40:32 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mBI4eJME021967 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 18 Dec 2008 05:40:19 +0100 Received: from INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 18 Dec 2008 05:40:19 +0100 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 18 Dec 2008 10:10:17 +0530 From: "Bhatia, Manav (Manav)" To: "rja@extremenetworks.com" , opsec wg mailing list Date: Thu, 18 Dec 2008 10:10:17 +0530 Thread-Topic: [OPSEC] minutes part 2 Thread-Index: Aclfm+xexFodDp+rTzG421iwYA7SZgBKAWPA Message-ID: <7C362EEF9C7896468B36C9B79200D83547FF9F3A@INBANSXCHMBSA1.in.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, I was away and could not respond earlier. > First, let me observe that IGP attacks are all insider attacks. > Sites routinely block IGP packets from entering from outside > their administrative domain. (This would be a sensible thing > for OPsec to recommend if it hasn't already done so.) > Similarly, ISPs normally block IGP packets from arriving > on customer-facing interfaces or other exterior interfaces. You btw cannot do this if IPSec is deployed. Look at the discussions in IPSECME for more details. > > Second, prospective attackers are both smart and lazy. They > are not likely to use a computationally expensive attack > vector (e.g. something cryptographic) when a simpler/easier > attack (e.g. DoS on the router CPU) exists. Would you like to elaborate on what constitutes a simpler/easier attack? Most of the vendors now provide protection against the simple/easy attacks that you are probably alluding to. > > Third, I am not aware of any active attacks on any deployed > IGP. I've worked at more than one network operator in the > past, and for multiple equipment suppliers. I've never heard > of even one. If active attacks were widespread or common, > then they would have received much more reporting in the > trade press (as different from the zero reports that I've > seen over the past ~20 years). I agree. However, you might understand that operators may not go out of their way to make this public. Irrespective of the above, the OPSEC WG doc draft-ietf-opsec-routing-protocols-crypto-issues-00 makes no such claims. It just lists down the possible holes that exist despite using cryptographic authentication mechanisms in the IGPs. This is not the first time such a discussion (spoofing in routing) has been brought about. It has been discussed several times in the RPSEC WG, individual routing WGs, KMART BOF, etc. and its for the first time that I am hearing somebody assert that security is not an issue in routing protocols. > > Fourth, the *only* goal of the various cryptographic IGP > authentication mechanisms (excepting: RFC-2154) always > has been to remove only the "passive attack" risks described > long ago in RFC-1704. Such passive attacks are trivially > easy to mount, even easier than a simple DOS attack, which > is why they are sensible to protect against. Again, would you mind expounding on this? > > Fifth, the existing cryptographic authentication mechanisms > are not really widely deployed operationally. Many enterprise Really? We have several customers who use cryptographic authentication mechanisms. If you doubt this you could post a survey on nanog. > users don't enable any form of authentication. Some enable > clear-text passwords; relatively few bother to enable > cryptographic authentication. Among ISPs, security mechanisms > are more widely deployed, but even in that community the > existing cryptographic authentication mechanisms appear not > to be widely used today. This is not because operators/users > are silly or uninformed. Instead, this is because they are > performing sensible risk/threat analyses and deploying what > actually makes sense for their operational environments. > > % OSPF cryptographic sequence number spoofing or replay > > From a technical perspective, these are solved problems. > Please see RFC-2154. Note that the absence of commercial > implementations of RFC-2154 reflects the total absence > of user/operator concern about either of these issues, > along with user/operator concern about the complexity > of a digital signature approach. I have not yet read the entire thread but you seem to offer 2154 as a panacea to all security issues, which imo is without any basis and foundation. A quick glance through 2154 reveals some issues and I am sure there are a LOT of other issues that could be present. Mutable fields are not covered by the digital signatures and can thus be exploited. 2154 mandates globally synchornized clocks between all trusted entities, something that is definitely not easy to achive given that clock synchronization could itself be exploited. Then you must also appreciate that there hasn't been any effort employed to study weakness in 2154 as this isnt deployed. So, lets leave this out of draft-ietf-opsec-routing-protocols-crypto-issues-00. > vulnerabilities in either Keyed-MD5 or HMAC-MD5 as used by > IETF routing protocols. By contrast, moving to SHA will > significantly increase a router's vulnerability to DOS attacks, I think this is a very irresponsible statement to make since your comments seem to be based on specific router implementations. A good implementation can do this without exposing the CPU for DOS attacks. > while providing negligible decrease in risk. (Also see > the comments 3 paragraphs down about SHA's own issues.) > > There is only one known user with any interest in SHA > authentication for routing protocols. They have said > that the only reason for that interest is "policy compliance". > Even they have not yet indicated that SHA support is required > of their equipment suppliers. > > Further, there are no known shipping implementations of > SHA authentication for any IETF-specified IGP. (I don't > know of any that are even "in progress".) I know of atleast two vendors who are working on this. Contact me offline if you want me to connect you to the people in charge of this work. > > % Keys shared across the broadcast domain, > % need to move to a stronger key identifier. > > 1. All IGPs multicast/broadcast their update packets, > so sharing a key across that same multicast/broadcast > domain is not a silly approach. Nobody is contesting this. However, this has some obvious issues, and we should see if we can solve this. > 2. Adding a Key-ID does not actually increase the > security of anything. It can make it slightly simpler You probably misunderstood the advantages incurred by using a Key ID. > for an implementation to locate the correct Security > Association to use in attempting to authenticate a > received packet, however the most widely deployed I repeat, you are again, referring to the implementation that you are aware of. I would urge you not to make such sweeping statements about routing implementations. > implementations *ignore* the Key-ID and instead just > try all configured and valid SAs on the router. See above. BTW, one gain of a Key ID is to avoid the very behavior that you have described above. > > % For OSPFv3 relies on ipsec, because manual key sequence number, > % replay protection cannot be used. > > See comment up top with reference to RFC-2154. See comment on top. > > % IS-IS MD5 but no sequence number not notion of keyid > % for pdu key must be validated. > > See previous comments. > > Separately, IS-IS is carried directly over the link-layer, > so off-link attacks are automatically precluded. This means > that the only possible threat model is an on-link insider. > There are simpler/easier attacks (e.g. DOS) on the routing > infrastructure. So adding a sequence number doesn't really matter. > Again, the KeyID is merely an implementer convenience, rather than > some form of risk reduction. We don't even recommend adding sequence number to IS-IS. However, it is just brought to the reader's notice. If there was any intent of doing so then we would have added this in draft-ietf-isis-hmac-sha-07.txt > % ripv2, no authentication of ip or udp headers. can change > % source address and receiver will still think it's a valid > % neighbor > > If MD5 authentication is enabled, packets can't be forged. Yes, but that doesn't preclude the possibility of an attack. I remember sending you an email about this some time back. Please read section 6 of draft-ietf-opsec-routing-protocols-crypto-issues-00.txt > % Second draft, minimum cryptographic requirements. the fact is > % cryptographic algorithms continue to be attacked. we need to > % keep track of this. the idea of this document is to keep > % modifying it but to track the minimum requirements for > interoperability > > I see this document as largely valueless. Most users/operators > aren't enabling any form of cryptographic authentication today, > because their risk/threat environment makes that not sensible > for their operational domain. Again, a very wrong assertion. > I am not aware of *any* known attacks on any deployed IGP with > any form of cryptographic authentication configured. If someone > has actually seen such himself/herself, please provide the details > here as that would be significant news. I agree. However, this doesn't mean that we should not highlight the issues that exist in the current crypto protection mechanisms. Please look at RFC 4593. Do you think all the threats mentioned there have actually been seen in the wild? Cheers, Manav _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Thu Dec 18 05:01:59 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A02DC3A69AA; Thu, 18 Dec 2008 05:01:59 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1A6D3A69AA for ; Thu, 18 Dec 2008 05:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A52PejiZWgYt for ; Thu, 18 Dec 2008 05:01:56 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id D06D33A6994 for ; Thu, 18 Dec 2008 05:01:54 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mBID0tXA013471 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 18 Dec 2008 14:00:57 +0100 Received: from INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 18 Dec 2008 14:00:55 +0100 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 18 Dec 2008 18:30:53 +0530 From: "Bhatia, Manav (Manav)" To: "rja@extremenetworks.com" , opsec wg mailing list Date: Thu, 18 Dec 2008 18:30:53 +0530 Thread-Topic: [OPSEC] minutes part 2 Thread-Index: Aclfs/clIhIpv118Rhio/6cdbJm1uwBTlZWw Message-ID: <7C362EEF9C7896468B36C9B79200D83547FFA2C1@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> In-Reply-To: <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, > On 16 Dec 2008, at 12:27, Vishwas Manral wrote: > > Thanks for the information about insider attacks. I have > raised issues > > with using IPsec ESP for OSPFv3 protection about 3 years back, as we > > cannot block packets in all such cases (as the firewall may not know > > of the contents inside the ESP packet). > > Your claim above is not obvious. > Please explain when/why you believe the claim above is true. It is impossible for firewalls and intermediate routers to differentiate between encrypted ESP and ESP NULL packets by simply examining them because of the way ESP is defined. This poses problems for the firewalls since such packets (OSPFv3) cannot be filtered and identified. You could read either of the drafts for more details: draft-ietf-ipsecme-traffic-visibility draft-bhatia-ipsecme-esp-null-00.txt > >> Third, I am not aware of any active attacks on any deployed > >> IGP. I've worked at more than one network operator in the > >> past, and for multiple equipment suppliers. I've never heard > >> of even one. If active attacks were widespread or common, > >> then they would have received much more reporting in the > >> trade press (as different from the zero reports that I've > >> seen over the past ~20 years). If the intention is to only provide protection against passive attacks then you don't need cryptographic authentication - You can very well do with clear text passwords. > > > > This seems to contradict what you stated as the first point about > > "First, let me observe that IGP attacks are all insider attacks." > > Not at all. This looks like an English language issue to me: > > - All IGP attacks would have to be insider attacks, > because external packets are normally filtered anyway. > - I am not aware of any IGP attacks ever occurring in the > deployed world. There might be some, but I am not aware > of any published reports during the past ~20 years. > - If someone has seen an actual active attack on any IGP, > that would be VERY interesting to learn more about. > > > Well we do not have to wait for the first attack to act, we need to > > react even before the attacks occur. You may have noted a > similar move > > in all Security groups even though attacks themselves have > not occured > > yet. I agree. You don't need to wait for attacks to happen before you start exploring other options. > > Network operators have a range of mechanisms available now in shipping > routers. Which mechanisms, if any, make sense to deploy is entirely > up to their judgement -- based on their risk/threat model for their > specific deployment. > > > Also note we have to consider the havoc to the forwarded > traffic that > > can be caused if the routing infrastructure is compromised. So the > > effect of an attack is more than just attacking an end user site. > > Again, there are a range of existing mechanisms that network operators > can choose to use -- and there seem to be no reports of any IGP attack > in the real world. Then you don't need cryptographic authentication for IGPs. Cleartext should be good enough. > > >> Fourth, the *only* goal of the various cryptographic IGP > >> authentication mechanisms (excepting: RFC-2154) always > >> has been to remove only the "passive attack" risks described > >> long ago in RFC-1704. Such passive attacks are trivially > >> easy to mount, even easier than a simple DOS attack, which > >> is why they are sensible to protect against. > > Agree partially. It is a goal but not the only goal of > cryptographic > > mechanisms. > > You personally might have different goals for IGP authentication, > but the various mechanisms extant (excepting RFC-2154) were only > designed to protect against passive attacks (as described in > RFC-1704). I find it strange that you find computing SHA computationally expensive (you stated this multiple times here on this list), while having no qualms on the overhead incurred when computing full digital signatures. Public Key Cryptography is *very* expensive and it drastically slows down the performance of the router. Then you have this problem of key distribution and somehow certifying the public key, etc. > > I have either authored or co-authored every one of those IGP > mechanisms > (e.g. the OSPF MD5 mechanism is why I get the acknowledgement in the > OSPF RFCs). They protect against a limited set of issues. The > limitations are widely understood in the community. For example, .. which is why we're documenting them in draft-ietf-opsec-routing-protocols-crypto-issues-00.txt. > at the BOF held at IETF/Dublin, the entire room appeared to understood > from the beginning that the current mechanisms are very > limited. I was > quite clear in my comments during that BOF that the current mechanisms > are limited. Then why do you mind listing them out? > > If one wants more, then the work that other folks have done with > "Digital Signatures" (RFC-2154) seems like the right direction to go. > That approach provides MUCH more comprehensive protections than > any other current mechanisms. (This is all a rehash of comments .. at an additional cost that you seem to conveniently forget. Also note from my previous email on the list that there are still some holes in the digital signature scheme. > I made during the KMART BOF at IETF/PHL, not all of which comments > made it into the minutes.) > > IS-IS and RIP likely would benefit from having equivalent > specifications > developed; for OSPF, RFC-2154 already exists. See my previous points. Lets not talk about 2154 and concentrate on the two drafts in question: draft-ietf-opsec-routing-protocols-crypto-issues-00.txt draft-bhatia-manral-igp-crypto-requirements-03.txt I know you are responding to the minutes posted on the list. However, since those are related to these drafts, I would urge you to read the above drafts and then comment specifically on the drafts. This imo would be more productive for the WG. > > (I have no personal interest in developing such "Digital Signature" > specifications for either IS-IS or RIP, but perhaps other folks here > do. I think it would be helpful to have the specifications completed > and openly specified so that users who wanted something stronger > could ask for something specific.) > > > >> % OSPF cryptographic sequence number spoofing or replay > >> > >> From a technical perspective, these are solved problems. > >> Please see RFC-2154. Note that the absence of commercial > >> implementations of RFC-2154 reflects the total absence > >> of user/operator concern about either of these issues, > >> along with user/operator concern about the complexity > >> of a digital signature approach. > > IPsec with Manual Keying still states there can be no Replay > > protection. > > RFC-2154 does not use IPsec. So a comment about IPsec > is orthogonal to the discussion. Please go read RFC-2154. > [ .. ] > > Moving to HMAC-SHA1 does mean that the CPU on a router > receiving a DOS attack via some IGP would be more severely > impacted (because SHA1 is more computationally expensive > than MD5).[2] As I have already mentioned in my earlier mail, this assertion is without any foundation and is perhaps based on router implementations that you are aware of. [ .. ] > So one can see that there is no obvious net gain for users moving > to HMAC-SHA for IGP authentication, relative to either HMAC-MD5 > or Keyed-MD5. Moreover, there is increased impact on the router CPU > (and hence the router control plane generally) of a prospective > DOS attack on IGP packets if any form of SHA is used.[2] Same as above. Cheers, Manav _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Thu Dec 18 07:57:15 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BE4D3A6973; Thu, 18 Dec 2008 07:57:15 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F382D3A691E for ; Thu, 18 Dec 2008 07:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIq52ab5b9Ns for ; Thu, 18 Dec 2008 07:57:13 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id F1E343A68B3 for ; Thu, 18 Dec 2008 07:57:12 -0800 (PST) Received: by bwz14 with SMTP id 14so1838982bwz.13 for ; Thu, 18 Dec 2008 07:57:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=FNzexRbpnGZ0dLlG0fMpuweubvBYBHIikNaPqUGlzmA=; b=SW4MdW0b2cM3Ysci9fEE2bYjhd/e7PzlDh8YAGGMmzgBE0yrFa+tb1ewIPhc2dI7yQ UlEb1rCtXDobYQPelwxUalKm3cLJc8M1WgQFuUCUmsT3P42ZOTF9FKkxL/HN9Ev3UN/d XIn9I4+YkMqMFcZqq9i6LvHD+MAVbCznmiQlE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Nm8CfzKr1iUGRTh1RVprl1A+m4pRsM7lTyJwXNzZUz0ATDjHBTX9t21d6c1BXDfv7R O78+u2jcyvFLTD5l0ynp93BvSi22fNX3GNhKPqc4g8JWUkQ7oe4jnygXozZR84pNnmWQ kG/GT+lXiG36ehhpLyHduiTL/ENGfQfqqs3rQ= Received: by 10.103.244.4 with SMTP id w4mr816582mur.11.1229615823822; Thu, 18 Dec 2008 07:57:03 -0800 (PST) Received: by 10.103.160.12 with HTTP; Thu, 18 Dec 2008 07:57:03 -0800 (PST) Message-ID: <92c950310812180757k3cb258e0jcc42755c54df01f4@mail.gmail.com> Date: Thu, 18 Dec 2008 21:27:03 +0530 From: "Glen Kent" To: "R Atkinson" In-Reply-To: <6A3E6D7A-6475-4B5D-B3A9-F865D3133736@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> <92c950310812171716j63bb07d5s2dcbd270fd8173ec@mail.gmail.com> <6A3E6D7A-6475-4B5D-B3A9-F865D3133736@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org >>> No, it is not discussed in the document. The RFC you mention is an >>> Experimental RFC. The draft talks about "Issues with Existing >>> Cryptographic Mechanisms with Routing Protocols". We can discuss the >>> same however (though I would feel it may not exactly fit the draft). >> >> You dont need to - its not required. > > You are formally declaring WG consensus ? > Curious. No, merely my opinion. Glen. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Thu Dec 18 08:01:42 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2103A6B39; Thu, 18 Dec 2008 08:01:42 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7877D3A6B35 for ; Thu, 18 Dec 2008 08:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pM6ntu-J-PU4 for ; Thu, 18 Dec 2008 08:01:40 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 33BDD3A6955 for ; Thu, 18 Dec 2008 08:01:40 -0800 (PST) Received: by bwz14 with SMTP id 14so1848773bwz.13 for ; Thu, 18 Dec 2008 08:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=7ZXsbkQAaUXTRTt5IU2OcmN9VZQW7Ikt/mw8JzayIdg=; b=N1A/4YLCXsrkqmAoTEKccUc61m+ybcVRdgYtv5PyYSCUHKdG6oOuK16RsGV81FIkUf Qg4mMnC9+rhvh3Zw07Si92WWKK7TmpjEi1tXBXCFsTwQCSj3gwDBS2XMRz/VsSosyA+D gi2aeAuYxcHaLBPlIfo7JvPMiKxBVO5PR0kOs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=JcOb+8lbAmtLdejSd8jUwGGfCHtALxmW0FG7JhBi3JYOTv6fA1ko8qaPwdzX90Hcft +NOt/KlLu+BBTcOVSMHqm7lacIiutL9uoAZhynyo+CFEkjKspQuyydcBRcOjP7Dg9YXg EZDDN8Z48/HbNEAcTSl+1sVZtgQUaaRoyFlTs= Received: by 10.103.189.15 with SMTP id r15mr800858mup.126.1229616090974; Thu, 18 Dec 2008 08:01:30 -0800 (PST) Received: by 10.103.160.12 with HTTP; Thu, 18 Dec 2008 08:01:30 -0800 (PST) Message-ID: <92c950310812180801i10ac5f07l4ed58c87778ca9ba@mail.gmail.com> Date: Thu, 18 Dec 2008 21:31:30 +0530 From: "Glen Kent" To: "R Atkinson" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <92c950310812161620j7d8aaa16m553940edadbe6d8f@mail.gmail.com> <12201E12-8A0B-4FBE-95A9-5C8B23DA46EC@gmail.com> <92c950310812171704x76e374bbv1bd74d74f5ca755b@mail.gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org >> Its experimental. Lets leave it out of the discussion. > > It is real and it is (IMHO) a whole lot better than anything > else we have -- and I understand at least one implementation > exists. So we should include it in the discussion. Is there any deployment of the same? Is the WG interested in this? Glen _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Thu Dec 18 11:52:43 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1243A6A1F; Thu, 18 Dec 2008 11:52:43 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B57EC3A6A1F for ; Thu, 18 Dec 2008 11:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.832 X-Spam-Level: X-Spam-Status: No, score=-5.832 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aHMkUEcq+Lf for ; Thu, 18 Dec 2008 11:52:41 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id EB0643A680C for ; Thu, 18 Dec 2008 11:52:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,244,1228089600"; d="scan'208";a="116893335" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 18 Dec 2008 19:52:33 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBIJqXCq013770; Thu, 18 Dec 2008 11:52:33 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id mBIJqXqN011250; Thu, 18 Dec 2008 19:52:33 GMT Received: from xmb-sjc-218.amer.cisco.com ([171.70.151.151]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Dec 2008 11:52:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Dec 2008 11:51:55 -0800 Message-ID: <60C4A248E730F249990993E3B9BD44D806E3788F@xmb-sjc-218.amer.cisco.com> In-Reply-To: <77ead0ec0812171919t5c160a2fl423805c8ad0941c3@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] Prospective issue with IPsec ESP-NULL & IGP packets thread-index: Aclgv333o9Yj1K8ATIeQ8eLRQLfwAwAik38A References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com><77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com><89F12E27-304C-41AD-BC27-556BD9FA7040@gmail.com><77ead0ec0812161851q204bd1e7nd9fc57538d161794@mail.gmail.com><596A619D-6D7B-421E-A43C-47AD1762093F@gmail.com><77ead0ec0812170814j3c34ea6aof7df345adfeee56f@mail.gmail.com> <77ead0ec0812171919t5c160a2fl423805c8ad0941c3@mail.gmail.com> From: "Darrel Lewis (darlewis)" To: "Vishwas Manral" , "R Atkinson" X-OriginalArrivalTime: 18 Dec 2008 19:52:33.0446 (UTC) FILETIME=[2B0C2460:01C9614A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=669; t=1229629953; x=1230493953; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[OPSEC]=20Prospective=20issue=20with=20 IPsec=20ESP-NULL=20&=20IGP=20packets |Sender:=20; bh=m1ynObDi5zG0fVO/6f891tmDWZKhX7ZDuUmShXDzCs0=; b=M6+mrLCDrCy3aEJh4tca2bL2BqAjzd25s7Zn+oagZg6GU8PwtdYemqGRzu QQY1pL4KF9Ebi+huQJgK4Pd96vvCHMifseOXd512ZbFR2fxI6vSBa13A56Wo +4hnEkklbYgGE/SpvFT3wJITj6TMDX470QtJtHbvI0FI4QOP+uCJI=; Authentication-Results: sj-dkim-1; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: opsec@ietf.org Subject: Re: [OPSEC] Prospective issue with IPsec ESP-NULL & IGP packets X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org > Hi Ran, > > As you have sent so many mails with so much text would it be > possible for you to point out which mail I should read. > > I am unable to understand how you can say ESP packets can be > filtered at the edge based on the content. That is a problem > IPsecme is trying to solve. > Vishwas, I think you can in theory filter all packets at the edge based on their destination. Why would you allow anyone to send ESP packets to your infrastructure addresses? I believe this is the point Ran is trying to make. Infrastructure hiding/filtering is orthogonal to encryption between infrastructure routers. -Darrel _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Thu Dec 18 11:59:55 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FEF73A6B57; Thu, 18 Dec 2008 11:59:55 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5116A3A6B57 for ; Thu, 18 Dec 2008 11:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q3w49JNlQ9y for ; Thu, 18 Dec 2008 11:59:53 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 62CA83A69F3 for ; Thu, 18 Dec 2008 11:59:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,244,1228089600"; d="scan'208";a="116896296" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 18 Dec 2008 19:59:46 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mBIJxiiL026783; Thu, 18 Dec 2008 11:59:44 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBIJxiuD028584; Thu, 18 Dec 2008 19:59:44 GMT Received: from xmb-sjc-218.amer.cisco.com ([171.70.151.151]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Dec 2008 11:59:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Dec 2008 11:59:24 -0800 Message-ID: <60C4A248E730F249990993E3B9BD44D806E3789A@xmb-sjc-218.amer.cisco.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D83547FFA2C1@INBANSXCHMBSA1.in.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] minutes part 2 thread-index: Aclfs/clIhIpv118Rhio/6cdbJm1uwBTlZWwABH4ktA= References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com><90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <7C362EEF9C7896468B36C9B79200D83547FFA2C1@INBANSXCHMBSA1.in.alcatel-lucent.com> From: "Darrel Lewis (darlewis)" To: "Bhatia, Manav (Manav)" , , "opsec wg mailing list" X-OriginalArrivalTime: 18 Dec 2008 19:59:44.0464 (UTC) FILETIME=[2BF44500:01C9614B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1430; t=1229630384; x=1230494384; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[OPSEC]=20minutes=20part=202 |Sender:=20; bh=Q6+SpKG91KVJMBGTr5H++E4hY9gfk+XfAqGfZGkbkuU=; b=ivhPEULp2dcUw/2UmoD4eOwKcwhF2+IJ57N3Fi4btIxa7LmIC/O+lkH25h rQ2FJvlw4xaSHA8oaDGxrxZbj9OKkKoSTj5YkkiUL6+0qV60p993Nba9xymh rB95c80W7P; Authentication-Results: sj-dkim-4; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org > Hi Ran, > > > On 16 Dec 2008, at 12:27, Vishwas Manral wrote: > > > Thanks for the information about insider attacks. I have > > raised issues > > > with using IPsec ESP for OSPFv3 protection about 3 years > back, as we > > > cannot block packets in all such cases (as the firewall > may not know > > > of the contents inside the ESP packet). > > > > Your claim above is not obvious. > > Please explain when/why you believe the claim above is true. > > It is impossible for firewalls and intermediate routers to > differentiate between encrypted ESP and ESP NULL packets by > simply examining them because of the way ESP is defined. This > poses problems for the firewalls since such packets (OSPFv3) > cannot be filtered and identified. > If this discussion is specific to ISPs needing to prevent customers from attacking their IGP, then you are (I think) mistaken in specifying the need for PE routers who implement infrastructure access control to examine the data inside the packets. There is no reason (aside from lack of filtering features/performance on the PE) that a service provider should let customer originated ESP packets be forwarded toward its infrastructure. If this is a more general discussion about network filtering of ospfv3/ESP packets and intra-enterprise firewalling, then yes, I guess it could be problematic. -Darrel _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Thu Dec 18 15:12:56 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CDCE3A68AE; Thu, 18 Dec 2008 15:12:56 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FDA53A63EB for ; Thu, 18 Dec 2008 15:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWqj1Z9bSm6Y for ; Thu, 18 Dec 2008 15:12:54 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 28AF03A68AE for ; Thu, 18 Dec 2008 15:12:53 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mBINCcoP016991 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 Dec 2008 00:12:38 +0100 Received: from INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 19 Dec 2008 00:12:38 +0100 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 19 Dec 2008 04:42:36 +0530 From: "Bhatia, Manav (Manav)" To: "Darrel Lewis (darlewis)" , "rja@extremenetworks.com" , opsec wg mailing list Date: Fri, 19 Dec 2008 04:42:36 +0530 Thread-Topic: [OPSEC] minutes part 2 Thread-Index: Aclfs/clIhIpv118Rhio/6cdbJm1uwBTlZWwABH4ktAABuZC0A== Message-ID: <7C362EEF9C7896468B36C9B79200D835487C9AB7@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com><90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <7C362EEF9C7896468B36C9B79200D83547FFA2C1@INBANSXCHMBSA1.in.alcatel-lucent.com> <60C4A248E730F249990993E3B9BD44D806E3789A@xmb-sjc-218.amer.cisco.com> In-Reply-To: <60C4A248E730F249990993E3B9BD44D806E3789A@xmb-sjc-218.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Darrel, > If this is a more general discussion about network filtering of > ospfv3/ESP packets and intra-enterprise firewalling, then yes, I guess > it could be problematic. Yes, it is this case. Firewalling OSPFv3 is a pain with ESP. Cheers, Manav > > -Darrel > > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Thu Dec 18 20:04:13 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9DD23A67D9; Thu, 18 Dec 2008 20:04:13 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38FFA3A67D9 for ; Thu, 18 Dec 2008 20:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89l3AnTI3nJz for ; Thu, 18 Dec 2008 20:04:11 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 3DAB23A67AE for ; Thu, 18 Dec 2008 20:04:10 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mBJ43wgl030811 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 Dec 2008 05:03:58 +0100 Received: from INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 19 Dec 2008 05:03:58 +0100 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 19 Dec 2008 09:33:56 +0530 From: "Bhatia, Manav (Manav)" To: Glen Kent , R Atkinson Date: Fri, 19 Dec 2008 09:33:55 +0530 Thread-Topic: [OPSEC] minutes part 2 Thread-Index: AclhKe+jgxVyltBdRkGMP+2t01LAzgAZAX4w Message-ID: <7C362EEF9C7896468B36C9B79200D835487C9AE0@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <92c950310812161620j7d8aaa16m553940edadbe6d8f@mail.gmail.com> <12201E12-8A0B-4FBE-95A9-5C8B23DA46EC@gmail.com> <92c950310812171704x76e374bbv1bd74d74f5ca755b@mail.gmail.com> <92c950310812180801i10ac5f07l4ed58c87778ca9ba@mail.gmail.com> In-Reply-To: <92c950310812180801i10ac5f07l4ed58c87778ca9ba@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Glen, There was an implementation of RFC 2154 based on Gated but there are no known deployments of the same. I had a brief exchange with Sandy (SIDR chair and author of this RFC) and she too isn't aware of any deployments. Cheers, Manav > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] > On Behalf Of Glen Kent > Sent: Thursday, December 18, 2008 9.32 PM > To: R Atkinson > Cc: opsec@ietf.org > Subject: Re: [OPSEC] minutes part 2 > > >> Its experimental. Lets leave it out of the discussion. > > > > It is real and it is (IMHO) a whole lot better than anything > > else we have -- and I understand at least one implementation > > exists. So we should include it in the discussion. > > Is there any deployment of the same? Is the WG interested in this? > > Glen > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sat Dec 20 11:34:29 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44D93A68FC; Sat, 20 Dec 2008 11:34:29 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 507D73A68FC for ; Sat, 20 Dec 2008 11:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96t+mg1Y90-s for ; Sat, 20 Dec 2008 11:34:27 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 5DAEC3A683D for ; Sat, 20 Dec 2008 11:34:27 -0800 (PST) Received: from [192.168.11.143] (c-67-171-158-173.hsd1.wa.comcast.net [67.171.158.173]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id mBKJYEWZ044807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Dec 2008 19:34:15 GMT (envelope-from joelja@bogus.com) Message-ID: <494D48B6.9090302@bogus.com> Date: Sat, 20 Dec 2008 11:34:14 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: R Atkinson , opsec wg mailing list References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> In-Reply-To: <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV 0.93.3/8787/Sat Dec 20 07:10:43 2008 on nagasaki.bogus.com X-Virus-Status: Clean Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org R Atkinson wrote: > > On 16 Dec 2008, at 19:16, Vishwas Manral wrote: >> Thanks for the conclusion, but the talk here is about 2 documents. > > Actually, as the Subject line and my quotes from my very first note > made clear, all of my notes have solely been responses to the > *OPsec meeting minutes*. > > I object to the assertions in those minutes that: > - the SHA approaches are better/stronger than MD5 approaches. > [We have agreed that the evidence does NOT support such a > claim -- which claim appears to be in the meeting minutes.] > > - the WG should recommend/encourage/promote SHA approaches > over MD5 approaches. [which claim again appears to be > in the meeting minutes] Just as a point of order, I looked at the minutes and audio and I think their existence in the dialogue as stated in the minutes is accurate, if not work for word. >> What you seem to state is whether a particular crypto algorithm is >> better than the other for the IGP cases. > > I can't parse that, so I don't know what you mean. > Please re-phrase. > >> Please raise the issues in the correct forum. > > I have been all along. Please discontinue incorrect assertions > that this is not an appropriate forum for discussing items in > the OPsec WG meeting minutes. All day I've been raising operational > security issues within the OPsec WG. > >> If my language is not clear, do let me know if we can discuss the same >> in Hindi, Kumaoni, Gujarati or any other language that I know. I am >> sorry I am not as well versed in English. :)) > > Fair. Each of us do our best. :-) > I am a polyglot [RFC-2130], but I also don't know any > south Asian languages, terribly sorry. > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sat Dec 20 12:42:08 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D0463A695E; Sat, 20 Dec 2008 12:42:08 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618083A695E for ; Sat, 20 Dec 2008 12:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[AWL=-0.952, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzkPeb7M9qLo for ; Sat, 20 Dec 2008 12:42:05 -0800 (PST) Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7]) by core3.amsl.com (Postfix) with ESMTP id 92A7C3A67DD for ; Sat, 20 Dec 2008 12:42:05 -0800 (PST) Received: from [10.30.20.71] ([72.84.80.181]) by vms173007.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KC70005Y03KRE61@vms173007.mailsrvcs.net> for opsec@ietf.org; Sat, 20 Dec 2008 14:40:37 -0600 (CST) Date: Sat, 20 Dec 2008 15:41:47 -0500 From: RJ Atkinson In-reply-to: <7C362EEF9C7896468B36C9B79200D835487C9AE0@INBANSXCHMBSA1.in.alcatel-lucent.com> To: opsec@ietf.org Message-id: MIME-version: 1.0 (Apple Message framework v930.3) X-Mailer: Apple Mail (2.930.3) References: <92c950310812161620j7d8aaa16m553940edadbe6d8f@mail.gmail.com> <12201E12-8A0B-4FBE-95A9-5C8B23DA46EC@gmail.com> <92c950310812171704x76e374bbv1bd74d74f5ca755b@mail.gmail.com> <92c950310812180801i10ac5f07l4ed58c87778ca9ba@mail.gmail.com> <7C362EEF9C7896468B36C9B79200D835487C9AE0@INBANSXCHMBSA1.in.alcatel-lucent.com> Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 18 Dec 2008, at 23:03, Bhatia, Manav (Manav) wrote: > There was an implementation of RFC 2154 based on Gated but there are > no known deployments of the same. I had a brief exchange with Sandy > (SIDR chair and author of this RFC) and she too isn't aware of any > deployments. > > Cheers, Manav I am aware of deployment of RFC-2154 within the USG, as noted before on this list. Foundry Networks' online data sheet also claims that they implement RFC-2154. (I have not tried to check all vendors' data sheets.) Ran _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sat Dec 20 12:49:23 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12BC63A6A04; Sat, 20 Dec 2008 12:49:23 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E857C3A6A29 for ; Sat, 20 Dec 2008 12:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUpEny8e7inA for ; Sat, 20 Dec 2008 12:49:21 -0800 (PST) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by core3.amsl.com (Postfix) with ESMTP id 44A993A6962 for ; Sat, 20 Dec 2008 12:49:21 -0800 (PST) Received: from [10.30.20.71] ([72.84.80.181]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KC7003JP0HWESA0@vms044.mailsrvcs.net> for opsec@ietf.org; Sat, 20 Dec 2008 14:49:13 -0600 (CST) Date: Sat, 20 Dec 2008 15:49:08 -0500 From: RJ Atkinson In-reply-to: <494D48B6.9090302@bogus.com> To: Joel Jaeggli Message-id: <73A1BD57-AE0E-45E7-9EFD-085E0D737DBA@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v930.3) X-Mailer: Apple Mail (2.930.3) References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 20 Dec 2008, at 14:34, Joel Jaeggli wrote: > Just as a point of order, I looked at the minutes and audio and I > think > their existence in the dialogue as stated in the minutes is > accurate, if > not work for word. Joel, I have never doubted that the minutes were accurate. My disagreement is with parts of someone's comments that were made during the meeting. My apologies if I have not been clear on this (or other matters). Yours, Ran _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sat Dec 20 22:35:53 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21B813A6803; Sat, 20 Dec 2008 22:35:53 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3DD3A684B for ; Sat, 20 Dec 2008 22:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aN6+5v0mGQa4 for ; Sat, 20 Dec 2008 22:35:49 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 3C0633A6407 for ; Sat, 20 Dec 2008 22:35:48 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 2DAAF6B6667; Sun, 21 Dec 2008 03:35:38 -0300 (ART) Received: from notebook.gont.com.ar (122-83-231-201.fibertel.com.ar [201.231.83.122]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id mBL6ZRdn024994; Sun, 21 Dec 2008 04:35:33 -0200 Message-Id: <200812210635.mBL6ZRdn024994@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 21 Dec 2008 02:15:03 -0300 To: Joel Jaeggli , opsec wg mailing list From: Fernando Gont In-Reply-To: <494470BF.3030901@bogus.com> References: <494470BF.3030901@bogus.com> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sun, 21 Dec 2008 03:35:36 -0300 (ART) Subject: Re: [OPSEC] minutes part 3 (action items) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org At 11:34 p.m. 13/12/2008, Joel Jaeggli wrote: >* draft-gont-opsec-ip-security-01 > > Test consensus on list for accepting as a working group document > > > Preference for desired outcome, informational or BCP? > > Venues for cross area review, where should we socialize it > > Are there specifica areas that should get special > attention? I believe the high-order bit for action items relevant to this document is to test for consensus on list for accepting this document as a working group document. I guess that once we are working on this document, we can more formally ask for cross-area review. This does not contradict with what you posted... I'm just saying that we should probably pursue the action items for this document in the order you stated them. That is, first check for consensus for accepting this doc as a wg item, then discuss preference for the desired outcome, and then discuss how we could implement the cross area review. >* draft-gont-opsec-icmp-filtering-00 > > Are we concluded that feedback on structure provided during the > wg meeting was sufficient to proceed? I had asked this one the mailing-list already, and the feedback I got at the Minneapolis meeting didn't argue for a change in the structure of the document. So the document will continue "as is". > Seperate v6 document or not I will got back to the comments I had received on the v6 stuff. However, as I mentioned at the meeting, the high order bit was to agree on the structure of the document, as this would affect both the v4 and the possible v6 stuff. I will come back with some concrete proposals/alternatives for the v6 stuff asap, now that we have agreed on the most basic issue that was the structure of the whole document. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sun Dec 21 08:21:26 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5104B3A67B6; Sun, 21 Dec 2008 08:21:26 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DACFB3A67CC for ; Sun, 21 Dec 2008 08:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqDuKYQblz00 for ; Sun, 21 Dec 2008 08:21:24 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id D28893A6817 for ; Sun, 21 Dec 2008 08:21:23 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mBLGL6uP024059 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 21 Dec 2008 17:21:06 +0100 Received: from INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.1.311.2; Sun, 21 Dec 2008 17:21:06 +0100 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Sun, 21 Dec 2008 21:51:01 +0530 From: "Bhatia, Manav (Manav)" To: Joel Jaeggli , "opsec@ietf.org" Date: Sun, 21 Dec 2008 21:51:00 +0530 Thread-Topic: RE: [OPSEC] minutes part 3 (action items) Thread-Index: AcljiBzxyuHFmz89RCqQG2grQE4Q/w== Message-ID: <7C362EEF9C7896468B36C9B79200D835487CA153@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [OPSEC] minutes part 3 (action items) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org At 11:34 p.m. 13/12/2008, Joel Jaeggli wrote: > * draft-ietf-opsec-routing-protocols-crypto-issues-00 > > Does this document need to address pim-sm or rsvp I'd personally like to keep it restricted to routing protocols. Vishwas and I had pointed out certain problems in BFD crypto mechanisms on the BFD mailing list, and there was a suggestion to include the same in this draft, but I would like to keep this restricted to the existing list. > > Other substantive comments? > > Is it ready for last call after another rev? I'd like to hear from the WG members on what they'd like to see added/removed from this draft. > > * draft-bhatia-manral-igp-crypto-requirements-03 > > Accept as a working group document? We have posted a revised version based on the comments that we had received during the meet and on the list and would like to move the draft ahead. > > Issue about language must- should+ etc (proposed change has > circulated already) Yes. > > change of title (to include authentication) I'm not sure I understand this? Cheers, Manav _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Dec 22 21:13:30 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ABA928C135; Mon, 22 Dec 2008 21:13:30 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 155FA28C135 for ; Mon, 22 Dec 2008 21:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQZsZtcUDq71 for ; Mon, 22 Dec 2008 21:13:29 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 95CF428C130 for ; Mon, 22 Dec 2008 21:13:28 -0800 (PST) Received: by bwz14 with SMTP id 14so9235724bwz.13 for ; Mon, 22 Dec 2008 21:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=tKTP9VfyzJ9Lgri4KddJWoEbGEWxXom73AfecS7iSKQ=; b=utZvtR2fz9d5UlisiA8x9D19CngmJ3qGRfervyesds/YeSP2VCoMyvMp2rChjIgB5+ FjhrphIF+pMs7gFLzv5DPn/Ue7LEgYfAaWV/lU82KO2vzj5IVZTtXBcu1O/v31D3IR9C HkTGHu2L+5NpZqUxJZ9yUlfokDoNUcHZDet3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=sPDmf3q5HpuACNLDtynUAOKLWjecjTQ1aXNicnSNSHJQodcTcpn6MtiFk2jMc1JQs3 dPElXZIJ+rcq+hq4FaG4SOZv6VPCcVBYg4KU9JFxPKfpVyJBMAtrPlWsNYiAHJybr1Ka sCopUqaxlHK4UM+TOlMVirXy4Z0BfDSF0RSAc= Received: by 10.181.138.13 with SMTP id q13mr2592644bkn.95.1230009198258; Mon, 22 Dec 2008 21:13:18 -0800 (PST) Received: by 10.180.209.3 with HTTP; Mon, 22 Dec 2008 21:13:18 -0800 (PST) Message-ID: <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> Date: Mon, 22 Dec 2008 21:13:18 -0800 From: "Vishwas Manral" To: "Joel Jaeggli" In-Reply-To: <494D48B6.9090302@bogus.com> MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> Cc: opsec wg mailing list , R Atkinson Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Joel/ Ran, >> I object to the assertions in those minutes that: >> - the SHA approaches are better/stronger than MD5 approaches. >> [We have agreed that the evidence does NOT support such a >> claim -- which claim appears to be in the meeting minutes.] >> >> - the WG should recommend/encourage/promote SHA approaches >> over MD5 approaches. [which claim again appears to be >> in the meeting minutes] > > Just as a point of order, I looked at the minutes and audio and I think > their existence in the dialogue as stated in the minutes is accurate, if > not work for word. I find the following link for the approved algorithms for secure hashing: http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html , they include SHS algorithms but not MD5 ones. Though there is a line which states that: "After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols." MD5 is not amoung the approved algorithms for the same. Ran, I would like to hear your views on the same. Thanks, Vishwas _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 07:45:00 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104A13A6B18; Tue, 23 Dec 2008 07:45:00 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D67F28C0E4 for ; Tue, 23 Dec 2008 07:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x76VQzMejYwC for ; Tue, 23 Dec 2008 07:44:58 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 1F38D3A68EF for ; Tue, 23 Dec 2008 07:44:57 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so1345362qwe.31 for ; Tue, 23 Dec 2008 07:44:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=ibycQ9+lnCJnar7gFNdOLRfqv0MkptH/QIHm6l5Qkq4=; b=tEi1Yw2iqeyA3RLnZhjTrSIX2dj9Gk1DF1MfcZILXu4HioZoCpyUUPR09k8VekG5LU t2hNpauoiqgDz+4E4PbSwlZf2uY5VW8e5YdDRXe5AbAHCl+sK3k1Hpv4djJAWFNTjR71 kA6QQifxlBckvBD2dN/AUA2K0voPlUzBEoWx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=BqLg8kSOamQWsxjJfqsVI3+blU9DzlEKHNX4N8KdoEBlgLe28kvx2PcOXtiKn1G3K+ YcO8VAeDoP4buxlaL62NcqujzT5ghcq6EIbdL4DVBe39QtyrgLMSbHegESydWOmddsOd UCwLL8wpF/4i/HWucDIlalqCAbPPw+Ke6mjgg= Received: by 10.214.181.20 with SMTP id d20mr7586434qaf.378.1230047087634; Tue, 23 Dec 2008 07:44:47 -0800 (PST) Received: from ?10.30.20.71? (pool-72-84-80-181.nrflva.fios.verizon.net [72.84.80.181]) by mx.google.com with ESMTPS id 6sm1004345ywi.46.2008.12.23.07.44.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Dec 2008 07:44:47 -0800 (PST) Message-Id: <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 23 Dec 2008 10:44:36 -0500 References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Folks, Of course, NIST's approved algorithms list only contains NIST algorithms This ought not be surprising. Of course, non-NIST algorithms aren't on NIST's lists. That is a tautology. There is no news here. It is all entirely consistent with my prior statements. There are some organisations that *for policy reasons* prefer to use certain algorithms or algorithm families. A choice made to comply with (local or national) organisational policy is quite different from a claim that scientific evidence exists that one algorithm is better than some other algorithm (when evaluated in the context of a particular cryptographic mode -- comparing apples to apples). As the IETF is an international, global organisation, the IETF has so far declined to use *local or national policy* as the basis to endorse or reject any particular algorithm. This seems only proper as the IETF ought not prefer US policy over another country's policy in its decision making. This principle of using global scope for the IETF standards processes lies behind [RFC-1984]. Given the relatively recent information indicating "serious attacks" on SHA (the quote is from NIST [1]), including an acknowledged attack on SHA-1 [2], previous beliefs that SHA might be stronger are no longer supported by the science at hand. MD5 is also subject to "serious attacks" that have been published. So the data available says that both SHA and MD5 have cause for serious concern. Now, maybe someone has recently published some scientific, peer-reviewed, paper that compares MD5 and SHA (in the mode used by the IGPs for authentication). If such exists, a pointer to that paper would be helpful to everyone in the OPsec WG. Absent such a paper, the only *scientific* conclusion is that (1) there is cause for concern about both SHA and MD5 and (2) there is not enough data at the present time to prefer either of those algorithms over the other algorithm. A practical step might be for some folks (not including me !) to add some additional MAC algorithms to the set available for IGP authentication, to provide more choices to implementers. Apparently specifications for an AES-CBC MAC and a "Counter with CBC-MAC" have been created in recent years. [RFC-3566] [RFC-3610] (NOTE WELL: I haven't done a literature search on either of those, so I'm not recommending either one; instead, I am only noting that the universe is not limited to SHA or MD5, and providing some examples of other options by way of an existence proof.) Cheers, Ran rja@extremenetworks.com PS: The set of "First Round Candidates" to replace the existing SHA standards are listed at reference [3] below. [1] [2] [3] _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 09:18:40 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AD953A6B15; Tue, 23 Dec 2008 09:18:40 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DB083A67A1 for ; Tue, 23 Dec 2008 09:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3C7HvQ3xsqR for ; Tue, 23 Dec 2008 09:18:38 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.187]) by core3.amsl.com (Postfix) with ESMTP id 2F10B3A6A34 for ; Tue, 23 Dec 2008 09:18:37 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w1so1372037mue.9 for ; Tue, 23 Dec 2008 09:18:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=kRwNWvpKH3BxDpxjHvOZxPtCxF0ORvi4s34OpU11UzY=; b=sakVLBIkVNrP14sgiKBzjZb2VQB8LagN5iSlix0ogNckJC1+W+bN3ptATlTNSe/b9P wOLwfxCWVjqDiZpHSTM6A82MV1lJHQCuRpG7Y4jQAzHiNjysNFvYOpfZPODGu/xgEr3d XF5w/hUqjtLeJS4qJP0WuraiqQIxGeDcAT5tg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=wn0yyZ631aXyOKDb5A3Cw3+mpg2oxoNualCXCT9GGVrSdx7lGRJ0vBo5b+VAO6NLQF o76ZeshaLV+OFQcmM5JT6e4oI8t7InIn6ybuwHIpXJh4BssYworOeGpgv9mnteBKEfSY QaJHAoktHhq1TQdqdQUCXEq8Fh/JEGJKoWBrY= Received: by 10.103.240.15 with SMTP id s15mr2835437mur.82.1230052707280; Tue, 23 Dec 2008 09:18:27 -0800 (PST) Received: by 10.103.160.12 with HTTP; Tue, 23 Dec 2008 09:18:27 -0800 (PST) Message-ID: <92c950310812230918t751a6cat1fca546dad2b55ad@mail.gmail.com> Date: Tue, 23 Dec 2008 22:48:27 +0530 From: "Glen Kent" To: "R Atkinson" In-Reply-To: <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org > > Given the relatively recent information indicating "serious > attacks" on SHA (the quote is from NIST [1]), including an > acknowledged attack on SHA-1 [2], previous beliefs that SHA > might be stronger are no longer supported by the science at hand. > MD5 is also subject to "serious attacks" that have been published. > So the data available says that both SHA and MD5 have cause > for serious concern. OSPF WG charter (http://www.ietf.org/html.charters/ospf-charter.html) says "Nov 2008 Develop stronger authentication mechanisms for OSPFv2 and submit to IESG as a Proposed Standard". It is against this charter item that they're probably working on the draft-ietf-ospf-hmac-sha-03.txt. You might want to let them know that its not good enough, as SHA has same problems, if not any worse, than MD5. You also might want to look at http://www.ietf.org/proceedings/07mar/slides/ospf-3/sld2.htm which tells you why this particular draft was adopted as a WG doc. And isnt it ironic that you are also the author of RIP for SHA support (RFC 4822) and IS-IS extensions for SHA (draft-ietf-isis-hmac-sha-07.txt)? If there is no need for these, except for one customer that you tout, then you should have probably called these RFCs and drafts as RIP-SHA for and ISIS-SHA for . Why an RFC if they offer no benefit to the community? I am surprised, really I am, as to why you have still not drafted an OSPF SHA extension for your_favorite_customer? Glen _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 10:07:10 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727CD3A6B2B; Tue, 23 Dec 2008 10:07:10 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E753A6B2A for ; Tue, 23 Dec 2008 10:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YBxF0Y6BYjB for ; Tue, 23 Dec 2008 10:07:05 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 9D3863A6452 for ; Tue, 23 Dec 2008 10:07:04 -0800 (PST) Received: by bwz14 with SMTP id 14so10282266bwz.13 for ; Tue, 23 Dec 2008 10:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Ml53pTEDJS2iwKXq59V0cfPJOrkovGTOfbq235Kv22I=; b=nMWaVZ2L/d9QotkBJpQ7HSs9lWoryDphfpL/3YcS3gUcHMgkDRsQDvRZLQlboJ7rxh WYQzaXUgO2vqbN18mD6kbcqVn4TB833Llwl5FNRaN3ncRDU/CoM4u5blGq3QS5F9524G mosB+LrlZT9mx3VN6nRFjK8OI7TUk8u7i+rH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=pWg2RCloMtfEAQUsv36u+BAawNgyJIGWUFh4zSd9PP7rH4EwytY1Yf+vZvpMPYvcMv 3WDIktaxrThVucdewIbsPApmmNvFby/WNlvLMwozwoSjRbBUO7vvaMqnF1twxi12AOKm R4HBFG45uZ1GDVs09J7IAEMZY4cKLa+9gDJsc= Received: by 10.181.50.1 with SMTP id c1mr2823885bkk.3.1230055614218; Tue, 23 Dec 2008 10:06:54 -0800 (PST) Received: by 10.180.209.3 with HTTP; Tue, 23 Dec 2008 10:06:54 -0800 (PST) Message-ID: <77ead0ec0812231006u55443dacn1731f51a8e922b62@mail.gmail.com> Date: Tue, 23 Dec 2008 10:06:54 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, > Of course, NIST's approved algorithms list only contains > NIST algorithms This ought not be surprising. > > Of course, non-NIST algorithms aren't on NIST's lists. > That is a tautology. > > There is no news here. I am not trying to disseminate news here. The aim was to show that the link which has been updated 2 months back states the uses of SHA-2, etc is safe for hashing purposes. I wanted to know if you thought that information was not correct. Thanks, Vishwas > It is all entirely consistent with my prior statements. There > are some organisations that *for policy reasons* prefer to use > certain algorithms or algorithm families. > > A choice made to comply with (local or national) organisational > policy is quite different from a claim that scientific > evidence exists that one algorithm is better than some > other algorithm (when evaluated in the context of a > particular cryptographic mode -- comparing apples to apples). > > As the IETF is an international, global organisation, > the IETF has so far declined to use *local or national > policy* as the basis to endorse or reject any particular > algorithm. This seems only proper as the IETF ought not > prefer US policy over another country's policy in its > decision making. This principle of using global scope for > the IETF standards processes lies behind [RFC-1984]. > > Given the relatively recent information indicating "serious > attacks" on SHA (the quote is from NIST [1]), including an > acknowledged attack on SHA-1 [2], previous beliefs that SHA > might be stronger are no longer supported by the science at hand. > MD5 is also subject to "serious attacks" that have been published. > So the data available says that both SHA and MD5 have cause > for serious concern. > > Now, maybe someone has recently published some scientific, > peer-reviewed, paper that compares MD5 and SHA (in the mode > used by the IGPs for authentication). If such exists, a pointer > to that paper would be helpful to everyone in the OPsec WG. > Absent such a paper, the only *scientific* conclusion is that > (1) there is cause for concern about both SHA and MD5 and > (2) there is not enough data at the present time to prefer > either of those algorithms over the other algorithm. > > A practical step might be for some folks (not including me !) > to add some additional MAC algorithms to the set available > for IGP authentication, to provide more choices to implementers. > Apparently specifications for an AES-CBC MAC and a "Counter > with CBC-MAC" have been created in recent years. [RFC-3566] > [RFC-3610] (NOTE WELL: I haven't done a literature search > on either of those, so I'm not recommending either one; instead, > I am only noting that the universe is not limited to SHA or MD5, > and providing some examples of other options by way of an > existence proof.) > > Cheers, > > Ran > rja@extremenetworks.com > > PS: The set of "First Round Candidates" to replace > the existing SHA standards are listed at reference [3] below. > > [1] > [2] > [3] > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 10:21:31 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF003A67A1; Tue, 23 Dec 2008 10:21:31 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AEDF3A67A1 for ; Tue, 23 Dec 2008 10:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7c4DLLTN7TC for ; Tue, 23 Dec 2008 10:21:28 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 2F7923A6452 for ; Tue, 23 Dec 2008 10:21:28 -0800 (PST) Received: by bwz14 with SMTP id 14so10306262bwz.13 for ; Tue, 23 Dec 2008 10:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=clqOA3vIbFVyC64QRgtr2bUsku3kLICx7LbmN7KlqV4=; b=n+0Oocmz14ofnerPHEZO1zlJrit0s5sF5GLXFyAqM7Kmh82non0iEDJhS+5c1DBEks 2o6mG+zGiOC+zgafMBhITgNFQs06e5Fuv4bJ9xR0C6bIVETF3xulIZadObsSDPRBEj+m rCtVQL+gmTrC+9+MzFgweHJAZjq2yceHJEOIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=YVpw0PWgs9urYCgt5VTs22rSne8G7PEi0A8OmWlKv8Az08PYeU897vTnqqaxP0+F8w EChrnrxJh/qB52rvsUSBbWppiOfTlxvUc7jnTHAt1Vn1P/8DYs186wigSm8yUcEnmYv1 JJILfjLvPQ/ypQehNOuVkqk5olSoFlBSx4SiA= Received: by 10.181.37.6 with SMTP id p6mr347026bkj.29.1230056477491; Tue, 23 Dec 2008 10:21:17 -0800 (PST) Received: by 10.180.209.3 with HTTP; Tue, 23 Dec 2008 10:21:17 -0800 (PST) Message-ID: <77ead0ec0812231021g2a9b84a5q70533d5e0d74f7b4@mail.gmail.com> Date: Tue, 23 Dec 2008 10:21:17 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, One more interesting thing I noticed was that we are reccomending HMAC-SHA-1 over Keyed-MD5 for OSPF and RIP do you agree to this part? Thanks, Vishwas ===================================================== For OSPF implementations to interoperate, they must support one or more authentication algorithms in common that can be used in the cryptographic scheme of authentication. This section details the authentication algorithm requirements for standards conformant OSPF implementations. Old Old New Req. RFC Requirement Authentication Algorithm --- ------ ----------- ------------------------ MUST 2328 MUST- Keyed MD5 - - SHOULD+ HMAC-SHA-1 [OSPF-HMAC] - - MAY+ HMAC-SHA-256/HMAC-SHA-384/HMAC-SHA-512 On Tue, Dec 23, 2008 at 7:44 AM, R Atkinson wrote: > Folks, > > Of course, NIST's approved algorithms list only contains > NIST algorithms This ought not be surprising. > > Of course, non-NIST algorithms aren't on NIST's lists. > That is a tautology. > > There is no news here. > > It is all entirely consistent with my prior statements. There > are some organisations that *for policy reasons* prefer to use > certain algorithms or algorithm families. > > A choice made to comply with (local or national) organisational > policy is quite different from a claim that scientific > evidence exists that one algorithm is better than some > other algorithm (when evaluated in the context of a > particular cryptographic mode -- comparing apples to apples). > > As the IETF is an international, global organisation, > the IETF has so far declined to use *local or national > policy* as the basis to endorse or reject any particular > algorithm. This seems only proper as the IETF ought not > prefer US policy over another country's policy in its > decision making. This principle of using global scope for > the IETF standards processes lies behind [RFC-1984]. > > Given the relatively recent information indicating "serious > attacks" on SHA (the quote is from NIST [1]), including an > acknowledged attack on SHA-1 [2], previous beliefs that SHA > might be stronger are no longer supported by the science at hand. > MD5 is also subject to "serious attacks" that have been published. > So the data available says that both SHA and MD5 have cause > for serious concern. > > Now, maybe someone has recently published some scientific, > peer-reviewed, paper that compares MD5 and SHA (in the mode > used by the IGPs for authentication). If such exists, a pointer > to that paper would be helpful to everyone in the OPsec WG. > Absent such a paper, the only *scientific* conclusion is that > (1) there is cause for concern about both SHA and MD5 and > (2) there is not enough data at the present time to prefer > either of those algorithms over the other algorithm. > > A practical step might be for some folks (not including me !) > to add some additional MAC algorithms to the set available > for IGP authentication, to provide more choices to implementers. > Apparently specifications for an AES-CBC MAC and a "Counter > with CBC-MAC" have been created in recent years. [RFC-3566] > [RFC-3610] (NOTE WELL: I haven't done a literature search > on either of those, so I'm not recommending either one; instead, > I am only noting that the universe is not limited to SHA or MD5, > and providing some examples of other options by way of an > existence proof.) > > Cheers, > > Ran > rja@extremenetworks.com > > PS: The set of "First Round Candidates" to replace > the existing SHA standards are listed at reference [3] below. > > [1] > [2] > [3] > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 11:22:18 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76B853A6B31; Tue, 23 Dec 2008 11:22:18 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F7E73A6B31 for ; Tue, 23 Dec 2008 11:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABvMyN62F1zo for ; Tue, 23 Dec 2008 11:22:16 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 74D503A67D0 for ; Tue, 23 Dec 2008 11:22:16 -0800 (PST) Received: from [192.168.11.143] (c-67-171-158-173.hsd1.wa.comcast.net [67.171.158.173]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id mBNJM3xF025168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Dec 2008 19:22:03 GMT (envelope-from joelja@bogus.com) Message-ID: <49513A5B.7030307@bogus.com> Date: Tue, 23 Dec 2008 11:22:03 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: Glen Kent References: <92c950310812161620j7d8aaa16m553940edadbe6d8f@mail.gmail.com> <12201E12-8A0B-4FBE-95A9-5C8B23DA46EC@gmail.com> <92c950310812171704x76e374bbv1bd74d74f5ca755b@mail.gmail.com> <92c950310812180801i10ac5f07l4ed58c87778ca9ba@mail.gmail.com> In-Reply-To: <92c950310812180801i10ac5f07l4ed58c87778ca9ba@mail.gmail.com> X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV 0.93.3/8795/Tue Dec 23 17:58:21 2008 on nagasaki.bogus.com X-Virus-Status: Clean Cc: opsec@ietf.org, R Atkinson Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Glen Kent wrote: >>> Its experimental. Lets leave it out of the discussion. >> It is real and it is (IMHO) a whole lot better than anything >> else we have -- and I understand at least one implementation >> exists. So we should include it in the discussion. > > Is there any deployment of the same? Is the WG interested in this? Just to be clear here... since the context disappeared some messages back... RFC 2154 is what is being referred to here? Do we have deployments or operational experience to draw on? I note one of the original author's is a routine contributor to this list. > Glen > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 11:27:57 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACA143A6B35; Tue, 23 Dec 2008 11:27:57 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F4103A6B35 for ; Tue, 23 Dec 2008 11:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLel4hLuXlYn for ; Tue, 23 Dec 2008 11:27:55 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 4C1E33A67D0 for ; Tue, 23 Dec 2008 11:27:55 -0800 (PST) Received: from [192.168.11.143] (c-67-171-158-173.hsd1.wa.comcast.net [67.171.158.173]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id mBNJRg1S025378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Dec 2008 19:27:43 GMT (envelope-from joelja@bogus.com) Message-ID: <49513BAE.703@bogus.com> Date: Tue, 23 Dec 2008 11:27:42 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: RJ Atkinson References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> <73A1BD57-AE0E-45E7-9EFD-085E0D737DBA@extremenetworks.com> In-Reply-To: <73A1BD57-AE0E-45E7-9EFD-085E0D737DBA@extremenetworks.com> X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV 0.93.3/8795/Tue Dec 23 17:58:21 2008 on nagasaki.bogus.com X-Virus-Status: Clean Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org RJ Atkinson wrote: > > On 20 Dec 2008, at 14:34, Joel Jaeggli wrote: >> Just as a point of order, I looked at the minutes and audio and I think >> their existence in the dialogue as stated in the minutes is accurate, if >> not work for word. > > Joel, > > I have never doubted that the minutes were accurate. > My disagreement is with parts of someone's comments > that were made during the meeting. Understood. I was just confirming that we we all clear that what was said in the meeting was reflected in the minutes. > My apologies if I have not been clear on this (or > other matters). none required > Yours, > > Ran > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 11:32:30 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A1B3A67D0; Tue, 23 Dec 2008 11:32:30 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C313A67D0 for ; Tue, 23 Dec 2008 11:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngq10-lpMdKG for ; Tue, 23 Dec 2008 11:32:29 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id E7E373A6452 for ; Tue, 23 Dec 2008 11:32:28 -0800 (PST) Received: from [192.168.11.143] (c-67-171-158-173.hsd1.wa.comcast.net [67.171.158.173]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id mBNJWEgP025589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Dec 2008 19:32:14 GMT (envelope-from joelja@bogus.com) Message-ID: <49513CBD.9080508@bogus.com> Date: Tue, 23 Dec 2008 11:32:13 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: Fernando Gont References: <494470BF.3030901@bogus.com> <200812210635.mBL6ZRdn024994@venus.xmundo.net> In-Reply-To: <200812210635.mBL6ZRdn024994@venus.xmundo.net> X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV 0.93.3/8795/Tue Dec 23 17:58:21 2008 on nagasaki.bogus.com X-Virus-Status: Clean Cc: opsec wg mailing list Subject: Re: [OPSEC] minutes part 3 (action items) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Fernando Gont wrote: > At 11:34 p.m. 13/12/2008, Joel Jaeggli wrote: > >> * draft-gont-opsec-ip-security-01 >> >> Test consensus on list for accepting as a working group document >> >> >> Preference for desired outcome, informational or BCP? >> >> Venues for cross area review, where should we socialize it >> >> Are there specifica areas that should get special >> attention? > > I believe the high-order bit for action items relevant to this document > is to test for consensus on list for accepting this document as a > working group document. I guess that once we are working on this > document, we can more formally ask for cross-area review. agree > This does not contradict with what you posted... I'm just saying that we > should probably pursue the action items for this document in the order > you stated them. That is, first check for consensus for accepting this > doc as a wg item, then discuss preference for the desired outcome, and > then discuss how we could implement the cross area review. > > > >> * draft-gont-opsec-icmp-filtering-00 >> >> Are we concluded that feedback on structure provided during the >> wg meeting was sufficient to proceed? > > I had asked this one the mailing-list already, and the feedback I got at > the Minneapolis meeting didn't argue for a change in the structure of > the document. So the document will continue "as is". my opinion as well > >> Seperate v6 document or not > > I will got back to the comments I had received on the v6 stuff. However, > as I mentioned at the meeting, the high order bit was to agree on the > structure of the document, as this would affect both the v4 and the > possible v6 stuff. I will come back with some concrete > proposals/alternatives for the v6 stuff asap, now that we have agreed on > the most basic issue that was the structure of the whole document. I believe the question is does much of what we could address for icmp6 carry the same weight of operational experience that we have with ipv4 icmp messages? > Thanks! > > Kind regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 11:35:18 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375DD3A6B35; Tue, 23 Dec 2008 11:35:18 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E043A6B32 for ; Tue, 23 Dec 2008 11:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TluMAcikIb6W for ; Tue, 23 Dec 2008 11:35:15 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 611F03A67D0 for ; Tue, 23 Dec 2008 11:35:15 -0800 (PST) Received: from [192.168.11.143] (c-67-171-158-173.hsd1.wa.comcast.net [67.171.158.173]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id mBNJYpUd025619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Dec 2008 19:34:52 GMT (envelope-from joelja@bogus.com) Message-ID: <49513D5B.6010308@bogus.com> Date: Tue, 23 Dec 2008 11:34:51 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <7C362EEF9C7896468B36C9B79200D835487CA153@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D835487CA153@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV 0.93.3/8795/Tue Dec 23 17:58:21 2008 on nagasaki.bogus.com X-Virus-Status: Clean Cc: "opsec@ietf.org" Subject: Re: [OPSEC] minutes part 3 (action items) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Bhatia, Manav (Manav) wrote: >> change of title (to include authentication) > > I'm not sure I understand this? richard graveman said the following at the mic: Rich This is pretty much on target, I agree with the chair, that there are a number of little things we can comment on. I would suggest that the word authentication get up in the title because it just says cryptographic protection, becuase it only deals with authentication integrity. there are comments in some of these protocols about the need (or lack) of need for confidentiality that I reject out of hand because the need for it is a function of the operational enviroment not the implmentors view of the protocol. if you look in the ospf v3 spec it says hey, we recomend you do confidentiality because it's easy, whereas in these other specs it isn't so we don't. I reject that chain of logic. > Cheers, Manav > > > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 14:35:42 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 637F73A6AF5; Tue, 23 Dec 2008 14:35:42 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025B13A6AF5 for ; Tue, 23 Dec 2008 14:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkafz-DWbupx for ; Tue, 23 Dec 2008 14:35:40 -0800 (PST) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by core3.amsl.com (Postfix) with ESMTP id 20CF83A6859 for ; Tue, 23 Dec 2008 14:35:40 -0800 (PST) Received: from [10.30.20.71] ([72.84.80.181]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KCC00GKBPERKK7C@vms042.mailsrvcs.net> for opsec@ietf.org; Tue, 23 Dec 2008 16:35:20 -0600 (CST) Date: Tue, 23 Dec 2008 17:35:15 -0500 From: RJ Atkinson In-reply-to: <92c950310812230943w42039f1ekdbb36d0b196866d2@mail.gmail.com> To: opsec@ietf.org Message-id: <28F8420F-F293-4B0B-9898-AD579FEFEE8B@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v930.3) X-Mailer: Apple Mail (2.930.3) References: <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <92c950310812230918t751a6cat1fca546dad2b55ad@mail.gmail.com> <92c950310812230943w42039f1ekdbb36d0b196866d2@mail.gmail.com> Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 23 Dec 2008, at 12:43, Glen Kent wrote: >> And isnt it ironic that you are also the author >> of RIP for SHA support (RFC 4822) and IS-IS extensions for SHA >> (draft-ietf-isis-hmac-sha-07.txt)? No irony. The specifications solve a policy problem for the US DoD. I have said all along that policy was a legitimate reason for one user to make a choice preferring one algorithm or another. I've also said that IETF ought to be making its decisions on science, not based on local policy or national policy. My position is completely consistent. Maybe you've forgotten, but I used to work for the US DoD, as is very widely known in the IETF (check Google or past RFCs on that also). Folks I used to work with asked me to put together some drafts on IGP authentication to address their policy issue. I did so as a favour. No surprises there. As I'm not a mathematician, I took their advice and asked folks at NIST for help with the math. Matt Fanto was at NIST at the time (Google should help with that also) and provided the maths. One will further note that Matt acknowledged several NIST folks in RFC-4822. Now note that RFC-4822 was published several months *before* NIST's announcement of "serious attacks" on SHA. That document was in the usual queuing at RFC-Editor for some time before its publication. >> If there is no need for these, >> except for one customer that you tout, then you should have probably >> called these RFCs and drafts as RIP-SHA for and >> ISIS-SHA for . One could. I'm pretty indifferent about names. >> Why an RFC if they offer no benefit to >> the community? I am surprised, really I am, as to why you have still >> not drafted an OSPF SHA extension for your_favorite_customer? >> > > Ho ho! I just googled and learnt that you have also written > a draft on extending OSPF for SHA ! Now, isnt that surprising? :-) I have had drafts for all 3 IGPs -- using the same mathematics -- for several years now. It isn't a secret. I've been saying all along that one user's policy compliance desires has driven the work in this area. > Wonder why you wrote this draft when you know that SHA is no better > than MD5. (See at top: using SHA solves a policy problem for US DoD.) Separately, I did not know the SHA attacks at the time. In fact, I'm well *behind the curve* as I did not learn about the SHA attacks until fairly recently. > Also any particular reason why this isnt the one adopted by > the WG as the WG doc? Both the drafts look similar to me. In Minneapolis, the OSPF WG decided to adopt the same mathematics used for RIP and IS-IS for use with OSPF. One might want to look at those slides also. Cheers, Ran rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 14:45:45 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8B503A6B3B; Tue, 23 Dec 2008 14:45:45 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880593A6B3B for ; Tue, 23 Dec 2008 14:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eONcTyDIeEVs for ; Tue, 23 Dec 2008 14:45:43 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 48F333A67F2 for ; Tue, 23 Dec 2008 14:45:43 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so1568285ywj.49 for ; Tue, 23 Dec 2008 14:45:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=4xWdEcrDWQreqq6g2ULRyJX8c9lDumGBThD4Vq5g1l0=; b=Gzn4873m9l2JcNlCG9InzXxauCRrraAe+6FYfSgsSU459VRsRsC1tFXaRHjsnCiQVG PdVLBzaOkgPnqwe3WOKnFUd2DK0ZxyXvxZ003xVo4df79IJ7CkReeNqmKIbnLzXEikUe SGHPhGCoEnaINOQRkYvn/KXiJuZWzpddivs5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=RQpSYzcfa3NstPaImRBVwxMheO5+8ohdySOYgeQ6URWZu0fsk3i8/vbTQYsLkzfNhY KIeCNLW0fhXGtYN2BEDp4RmD7qxdaETSWjxIa5YzgEaQ7I3pvRUEC6rLwj+ASt+h88+0 dmZN9t879jUxdttg16d4owOH5331yZC0jcEGs= Received: by 10.100.48.19 with SMTP id v19mr4954936anv.46.1230072333092; Tue, 23 Dec 2008 14:45:33 -0800 (PST) Received: from ?10.30.20.71? (pool-72-84-80-181.nrflva.fios.verizon.net [72.84.80.181]) by mx.google.com with ESMTPS id c1sm14299025ana.16.2008.12.23.14.45.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Dec 2008 14:45:32 -0800 (PST) Message-Id: <8CA72870-DEB9-4979-8478-ED5467AF3DD3@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812231006u55443dacn1731f51a8e922b62@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 23 Dec 2008 17:45:31 -0500 References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <77ead0ec0812231006u55443dacn1731f51a8e922b62@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 23 Dec 2008, at 13:06, Vishwas Manral wrote: > I am not trying to disseminate news here. The aim was to show that the > link which has been updated 2 months back states the uses of SHA-2, > etc is safe for hashing purposes. NIST's Policy on Hash Functions This says precisely that: "The SHA-2 family of hash functions may be used by Federal agencies for all applications using secure hash algorithms." This is a statement of policy, granting permission to Federal agencies. It does not say that they are "safe", just that they "may be used by Federal agencies". It then follows with another policy statement urging non-use of SHA-1: "Federal agencies should stop using SHA-1 for digital signatures, digital time stamping, and other applications that require collision resistance as soon as practical..." Note that neither the NIST policy (URL above), nor the other NIST statements (2 URLs next) say that SHA-2 is "safe". In fact, the word "safe" doesn't appear at any of those URLs, as near as my web browser can tell. >> [1] >> [2]> > These 2 URLs above say that SHA has "serious attacks" and also that NIST is actively working to replace the current SHA algorithms. Earlier today, I provided a URL to NIST's list of candidates to replace SHA, which shows that work to be well underway. So far, the NIST documents you are citing support my statements. There are several URLs above. I'd encourage list members to go read them for themselves. :-) Cheers, Ran _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 14:48:39 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116813A6B3B; Tue, 23 Dec 2008 14:48:39 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270203A6B48 for ; Tue, 23 Dec 2008 14:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQym7D39Y+w5 for ; Tue, 23 Dec 2008 14:48:36 -0800 (PST) Received: from mail-gx0-f13.google.com (mail-gx0-f13.google.com [209.85.217.13]) by core3.amsl.com (Postfix) with ESMTP id 341803A67F2 for ; Tue, 23 Dec 2008 14:48:35 -0800 (PST) Received: by gxk6 with SMTP id 6so2389486gxk.13 for ; Tue, 23 Dec 2008 14:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=B+Rczed6GC8/6p8iHDWZZPcR9hUBcMZNhEk2ryDh70E=; b=p52U+VSRX1hLwgdcji0Hz4ep+yyqnnES+PeUfCqsgqbcEiosE3R9rv9u6ZUtkMhgB3 /U3MLn4YG+XSMgBj0EKqYoJ/y1h5gJwjujrWhu2u0nw55iJIkz1E7ovs175RCWW8M5Ca 273qw02I6m1yygR+Zye7JITH9YnrLDbdtvuBY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=Fk4MOYdj0mi7BHTmCbHJI78epNqPeGPo8sk745HehrzctTxwpGPJAN82+1POpNyzbh CaCrZFQ0mNE8mWjeWCT5aCWYLBh0Y+F1au6qtuvSiZ0dAMj8ta1wbtWDV7gFKTQpi704 v8awdu6t6ORg1fMpnYZwzl88wk+3xDfMWN6fc= Received: by 10.151.14.5 with SMTP id r5mr6246990ybi.248.1230072505774; Tue, 23 Dec 2008 14:48:25 -0800 (PST) Received: from ?10.30.20.71? (pool-72-84-80-181.nrflva.fios.verizon.net [72.84.80.181]) by mx.google.com with ESMTPS id o29sm926761elf.9.2008.12.23.14.48.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Dec 2008 14:48:25 -0800 (PST) Message-Id: <4A20D9A3-5A0B-4A11-AF7E-0773E0519B23@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812231021g2a9b84a5q70533d5e0d74f7b4@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 23 Dec 2008 17:48:24 -0500 References: <77ead0ec0812160927j77bf42c6mbccef8ccf55d1e16@mail.gmail.com> <90F75653-21D6-4D2B-9472-52F2BDF7510D@gmail.com> <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <77ead0ec0812231021g2a9b84a5q70533d5e0d74f7b4@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 23 Dec 2008, at 13:21, Vishwas Manral wrote: > One more interesting thing I noticed was that we are reccomending > HMAC-SHA-1 over Keyed-MD5 for OSPF and RIP do you agree to this part? > > Thanks, > Vishwas > ===================================================== > > For OSPF implementations to interoperate, they must support one or > more authentication algorithms in common that can be used in the > cryptographic scheme of authentication. > > This section details the authentication algorithm requirements for > standards conformant OSPF implementations. > > Old Old New > Req. RFC Requirement Authentication Algorithm > --- ------ ----------- ------------------------ > MUST 2328 MUST- Keyed MD5 > - - SHOULD+ HMAC-SHA-1 [OSPF-HMAC] > - - MAY+ HMAC-SHA-256/HMAC-SHA-384/HMAC- > SHA-512 > I don't think the current knowledge to hand supports the policy in the text you've quoted above. In the past, BEFORE the understanding that SHA has "serious attacks", then encouraging the use of SHA might have been widely deemed reasonable, but given the current data I don't see how one can draw that same conclusion now. Cheers, Ran rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 14:54:12 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46A33A6B4A; Tue, 23 Dec 2008 14:54:12 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6363228C175 for ; Tue, 23 Dec 2008 14:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGW6WxEJnXzm for ; Tue, 23 Dec 2008 14:54:11 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 7BF633A6B49 for ; Tue, 23 Dec 2008 14:54:11 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so1564444yxg.49 for ; Tue, 23 Dec 2008 14:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=2LnG002zzcAAmzX/X5TBZr9hee0T32seZdFsawsYOSE=; b=WmGkkTLvOmtPi6JxYdn63MRo9OISAIs42PNlTm5QCSadvJaqpSUmQJ2Z7bSd7OZfZZ OHLjA7DgPKSIGzitmBqkr2A+D0K7CrzAdSIpfDXN8/BKkaazxcky3Sm2o0gpEACI8e9I N9iYiO5S2DOpfkWkAvCAyCOYJ9/RSCi3uZWd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=Kpt7nDZE9SEAN4VcXb8aTURMSRIP3pHfnIkWO4pjo9C4+uS5k082+RxIS8sAoEhwBZ yt7B23mseSc/1SriNQ4RmH4KMx8H07JufNz8HyzzSrQMBDsQzH7eivWAHdtu2+gSV1Fg nmCoLPtUQjdLkwA0b/ng/5WQKDWbj2P/Mu66Q= Received: by 10.100.154.17 with SMTP id b17mr4931369ane.155.1230072841920; Tue, 23 Dec 2008 14:54:01 -0800 (PST) Received: from ?10.30.20.71? (pool-72-84-80-181.nrflva.fios.verizon.net [72.84.80.181]) by mx.google.com with ESMTPS id d21sm14368508and.46.2008.12.23.14.54.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Dec 2008 14:54:01 -0800 (PST) Message-Id: <81B44188-AB93-40D9-B335-09A0CC466CEF@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <49513A5B.7030307@bogus.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 23 Dec 2008 17:54:00 -0500 References: <92c950310812161620j7d8aaa16m553940edadbe6d8f@mail.gmail.com> <12201E12-8A0B-4FBE-95A9-5C8B23DA46EC@gmail.com> <92c950310812171704x76e374bbv1bd74d74f5ca755b@mail.gmail.com> <92c950310812180801i10ac5f07l4ed58c87778ca9ba@mail.gmail.com> <49513A5B.7030307@bogus.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 23 Dec 2008, at 14:22, Joel Jaeggli wrote: > Just to be clear here... since the context disappeared some messages > back... > > RFC 2154 is what is being referred to here? > > Do we have deployments or operational experience to draw on? Joel, I am told there is limited use of RFC-2154 within US DoD. I gather (from the URL provided earlier) that at least one commercial router vendor supports it. Note that I have not and do not propose that this WG recommend RFC-2154 for general use at this time. It would be unusual to recommend an experimental status RFC for widespread use. I suspect many folks would agree with that. I have proposed, and continue to believe, that a document talking about issues with IGP authentication mechanisms (and there are lots of potential issues with IGP authentication at present) ought also include analysis and discussion of RFC-2154. If RFC-2154 has issues, those would be useful to know in detail, and such a document would be an appropriate place for such information. Cheers, Ran _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 15:41:49 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9DE3A67F2; Tue, 23 Dec 2008 15:41:49 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE783A67A5 for ; Tue, 23 Dec 2008 15:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4bucE5js5Lr for ; Tue, 23 Dec 2008 15:41:47 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 12B3E3A67F2 for ; Tue, 23 Dec 2008 15:41:46 -0800 (PST) Received: from [192.168.11.143] (c-67-171-158-173.hsd1.wa.comcast.net [67.171.158.173]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id mBNNfXig035837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Dec 2008 23:41:34 GMT (envelope-from joelja@bogus.com) Message-ID: <4951772C.303@bogus.com> Date: Tue, 23 Dec 2008 15:41:32 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: R Atkinson References: <92c950310812161620j7d8aaa16m553940edadbe6d8f@mail.gmail.com> <12201E12-8A0B-4FBE-95A9-5C8B23DA46EC@gmail.com> <92c950310812171704x76e374bbv1bd74d74f5ca755b@mail.gmail.com> <92c950310812180801i10ac5f07l4ed58c87778ca9ba@mail.gmail.com> <49513A5B.7030307@bogus.com> <81B44188-AB93-40D9-B335-09A0CC466CEF@gmail.com> In-Reply-To: <81B44188-AB93-40D9-B335-09A0CC466CEF@gmail.com> X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV 0.93.3/8795/Tue Dec 23 17:58:21 2008 on nagasaki.bogus.com X-Virus-Status: Clean Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org R Atkinson wrote: > > On 23 Dec 2008, at 14:22, Joel Jaeggli wrote: >> Just to be clear here... since the context disappeared some messages >> back... >> >> RFC 2154 is what is being referred to here? >> >> Do we have deployments or operational experience to draw on? > > Joel, > > I am told there is limited use of RFC-2154 within US DoD. > > I gather (from the URL provided earlier) that at least one > commercial router vendor supports it. > > Note that I have not and do not propose that this WG recommend > RFC-2154 for general use at this time. I agree... > It would be unusual > to recommend an experimental status RFC for widespread use. > I suspect many folks would agree with that. As a foil for a thought experiment it's fine. We continue to demonstrate that the problem space has not been fully exhausted. > I have proposed, and continue to believe, that a document talking > about issues with IGP authentication mechanisms (and there are > lots of potential issues with IGP authentication at present) > ought also include analysis and discussion of RFC-2154. noted > If > RFC-2154 has issues, those would be useful to know in detail, > and such a document would be an appropriate place for such > information. > > Cheers, > > Ran > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 15:57:03 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C6AF28C17E; Tue, 23 Dec 2008 15:57:03 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C099B28C17E for ; Tue, 23 Dec 2008 15:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtOV3B7BlcuL for ; Tue, 23 Dec 2008 15:57:01 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 665CA28C179 for ; Tue, 23 Dec 2008 15:57:00 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so1290656fga.41 for ; Tue, 23 Dec 2008 15:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=edK87tRm7jqKavDaNIwmtkOrhHA1JkNZlUrHAT0uecs=; b=Z2xGVsvuc/MqWqGXf4cLighUL5HsHK/7a2EnLgkIp2GE6JuMWt9fdZ2BHTnyddHALH YRNq/2g6olwaddWv4uwhlO4AMSR+X3yiz35CkhSSfRpLe/smFPMcNF+V2sXZKv857Qo0 ckDTteFYii1/P/xB8IwftQfz3sL9Ty4seNGhs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=g1glAaVF3gEDJPdSIGSqAWI7v+rTZyMRwHsj82RfwpkkZB2OwbBWkADWm12D8Z5AWs BQP25VOZNr7aytfzrNqLzWSTMXzdM+8+1d6CEhZo4Q1jwq2pDmOkrafxNKtsvKcJWTLU YRa5SxGwXBitg6aqiKtwg2UoxpMlEHXwZ8ohs= Received: by 10.86.62.3 with SMTP id k3mr4746506fga.47.1230076609598; Tue, 23 Dec 2008 15:56:49 -0800 (PST) Received: by 10.86.3.7 with HTTP; Tue, 23 Dec 2008 15:56:49 -0800 (PST) Message-ID: <77ead0ec0812231556t73e24f17m9d52862672b22dc5@mail.gmail.com> Date: Tue, 23 Dec 2008 15:56:49 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <8CA72870-DEB9-4979-8478-ED5467AF3DD3@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <77ead0ec0812231006u55443dacn1731f51a8e922b62@mail.gmail.com> <8CA72870-DEB9-4979-8478-ED5467AF3DD3@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, Thanks for your replies. Snipping to relevent information, This is the portion I was referring to which you have conveniently skipped: "Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols." > "The SHA-2 family of hash functions may be used by Federal agencies > for all applications using secure hash algorithms." > > "Federal agencies should stop using SHA-1 for digital signatures, > digital time stamping, and other applications that require > collision resistance as soon as practical..." I am sorry to use the term safe. My intent was to state that SHA-1 has been mandated to be not used for particular applications, while .SHA-2 family is encouraged for use by protocol designers. Are we on the same page regarding this or not? Thanks, Vishwas _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 16:01:39 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5610328C18E; Tue, 23 Dec 2008 16:01:39 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2737E28C19A for ; Tue, 23 Dec 2008 16:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTe2pOpaaSCE for ; Tue, 23 Dec 2008 16:01:37 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 9E74228C18D for ; Tue, 23 Dec 2008 16:01:03 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so1291065fga.41 for ; Tue, 23 Dec 2008 16:00:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=rvHeTwNGG2kLm8SiAl7YrotVxzivncky/ICBykS59xg=; b=F/2c+wLsijz94WQ3uIA5r7U6nK3yD6Mhe9wavLpbZhQmJ+gALJR1T3H/+CESCUxU5t ooY0nrS5j1uZ/ELAGQlLL2SwTj2UFJU+4kG8fHTdFYe3m2zQOzH0holUG0zUgHhLCMV4 zXEaIaINNyiFoqpqJUmYCGWeT1rZQD3Ce5+IQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Sxsh9EjgvZDzZCmRBEYJ27P2A7H6pxPEtys46jKXQeURrwtjRCsCc3L/dN63UToA3t BjxGE6ZBR8BVQbHYXuP8uQHvXoCW97wcDooTR14e1lkGl+1NX5LTp3eIkStg1qAvCjPb odoYz8JTz4e7dU8grbyUCCfqsarTjg8kIA5jk= Received: by 10.86.100.19 with SMTP id x19mr4765299fgb.29.1230076853216; Tue, 23 Dec 2008 16:00:53 -0800 (PST) Received: by 10.86.3.7 with HTTP; Tue, 23 Dec 2008 16:00:52 -0800 (PST) Message-ID: <77ead0ec0812231600vbd7c8fejd3a72a67b200185c@mail.gmail.com> Date: Tue, 23 Dec 2008 16:00:52 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <4A20D9A3-5A0B-4A11-AF7E-0773E0519B23@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <77ead0ec0812231021g2a9b84a5q70533d5e0d74f7b4@mail.gmail.com> <4A20D9A3-5A0B-4A11-AF7E-0773E0519B23@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, Again snipping to the right information. >> Old Old New >> Req. RFC Requirement Authentication Algorithm >> --- ------ ----------- ------------------------ >> MUST 2328 MUST- Keyed MD5 >> - - SHOULD+ HMAC-SHA-1 [OSPF-HMAC] >> - - MAY+ HMAC-SHA-256/HMAC-SHA-384/HMAC-SHA-512 > I don't think the current knowledge to hand supports the > policy in the text you've quoted above. > > In the past, BEFORE the understanding that SHA has "serious > attacks", then encouraging the use of SHA might have been > widely deemed reasonable, but given the current data > I don't see how one can draw that same conclusion now. So are you stating that the current known vulnerabilities affect the HMAC constructs too? Thanks, Vishwas _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 16:42:14 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40AA28C192; Tue, 23 Dec 2008 16:42:14 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C1728C18E for ; Tue, 23 Dec 2008 16:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-XbCEgUYCbn for ; Tue, 23 Dec 2008 16:42:12 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 3BB8428C184 for ; Tue, 23 Dec 2008 16:42:12 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so1295300fga.41 for ; Tue, 23 Dec 2008 16:42:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=tuZY2I1oQM7+o4/HDYT4c9veB/FZLP1NJ/zCKcLQz1M=; b=nryZVu8qjT2CI0OTuTXMvENwptNXpu+Ia9faSE881xTp5VeXN71YWqB8n3GkH1SbyM lOIapSdUWOsTtFvMeHuQ1zywWD0oltoXIAOx+owODnCNjjx+GXUwm1PaNlOzgI6GKeV1 ZBfPSG00LlJFdyU5K0x3fUhLNcRR5PY5a/hzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=NDEn6hgSz0HEi5h0T7BNpgpWggNhReoXronzDnhc2vji31RxcTsT/695asXni1sVzj OUL+9bK6k6tJ95vu4KiGTHdypU7zIO/ooU2f6191ITEXfwjPmN7LeRZOaoIvPYQoy/Ag myMPIHzu8n0V1lHRhcTGf0inDTpfVqlPNwRFw= Received: by 10.86.65.9 with SMTP id n9mr4737447fga.61.1230079322151; Tue, 23 Dec 2008 16:42:02 -0800 (PST) Received: by 10.86.3.7 with HTTP; Tue, 23 Dec 2008 16:42:02 -0800 (PST) Message-ID: <77ead0ec0812231642me00ebceue465f19183039492@mail.gmail.com> Date: Tue, 23 Dec 2008 16:42:02 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <77ead0ec0812231600vbd7c8fejd3a72a67b200185c@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <77ead0ec0812231021g2a9b84a5q70533d5e0d74f7b4@mail.gmail.com> <4A20D9A3-5A0B-4A11-AF7E-0773E0519B23@gmail.com> <77ead0ec0812231600vbd7c8fejd3a72a67b200185c@mail.gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, Just some more information from the earlier link I sent you over: "After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). " So it seems in NIST view atleast SHA-1 with HMAC constructs is not affected to warrant a reccomendation to stop its use like for the other case. Thanks, Vishwas On Tue, Dec 23, 2008 at 4:00 PM, Vishwas Manral wrote: > Hi Ran, > > Again snipping to the right information. > >>> Old Old New >>> Req. RFC Requirement Authentication Algorithm >>> --- ------ ----------- ------------------------ >>> MUST 2328 MUST- Keyed MD5 >>> - - SHOULD+ HMAC-SHA-1 [OSPF-HMAC] >>> - - MAY+ HMAC-SHA-256/HMAC-SHA-384/HMAC-SHA-512 >> I don't think the current knowledge to hand supports the >> policy in the text you've quoted above. >> >> In the past, BEFORE the understanding that SHA has "serious >> attacks", then encouraging the use of SHA might have been >> widely deemed reasonable, but given the current data >> I don't see how one can draw that same conclusion now. > So are you stating that the current known vulnerabilities affect the > HMAC constructs too? > > Thanks, > Vishwas > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 23 20:35:45 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9CBE3A6B4F; Tue, 23 Dec 2008 20:35:45 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3009D3A6B52 for ; Tue, 23 Dec 2008 17:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HT2GDkuYsON7 for ; Tue, 23 Dec 2008 17:06:44 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 62BB73A6B4F for ; Tue, 23 Dec 2008 17:06:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,274,1228089600"; d="scan'208";a="218735921" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Dec 2008 01:06:34 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mBO16YdL001630 for ; Tue, 23 Dec 2008 17:06:34 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBO16YFh016923 for ; Wed, 24 Dec 2008 01:06:34 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Dec 2008 17:06:34 -0800 Received: from [10.21.147.221] ([10.21.147.221]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Dec 2008 17:06:34 -0800 Message-ID: <49518B19.4050803@cisco.com> Date: Tue, 23 Dec 2008 17:06:33 -0800 From: Michael Barnes User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: opsec@ietf.org X-OriginalArrivalTime: 24 Dec 2008 01:06:34.0439 (UTC) FILETIME=[DD384570:01C96563] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1164; t=1230080794; x=1230944794; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjbarnes@cisco.com; z=From:=20Michael=20Barnes=20 |Subject:=20FW=3A=20[OPSEC]=20minutes=20part=202 |Sender:=20; bh=uxW7t7eqUGccr3duek8RzQe9DDloDUmzmaIg96H+q9w=; b=cQJ2b4S0IhtEs5HLInsRDQKDMcxQXlrFR5ZUfS3cNuYJSol/+8maDgnIZE RjxZwmFVBxl9dFLwNG9IHk7UVIU3uFj6V5jZaZyFcVldPzSwlboqt+xLrgKd D+yT89BIMR; Authentication-Results: sj-dkim-4; header.From=mjbarnes@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Mailman-Approved-At: Tue, 23 Dec 2008 20:35:44 -0800 Subject: [OPSEC] FW: minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] > On Behalf Of R Atkinson > Sent: Wednesday, December 17, 2008 6.58 AM > To: opsec@ietf.org > Subject: Re: [OPSEC] minutes part 2 > > > Vishwas, > > Can we please get answers to these questions -- which in fact > are entirely on topic for the OPsec WG, since they are all > operational security matters ? > > (Single quotes are from me; double-quotes are from Vishwas' > earlier emails.) > 4: Availability of SHA mechanisms for IGP authentication > > Further, there are no known shipping implementations of > > SHA authentication for any IETF-specified IGP. > > (I don't know of any that are even "in progress".) > >> We know of a few including a big router vendor. :)) > > Which ? How many ? When ? > Are they shipping now or in progress now ? I am working on an enhancement to use HMAC SHA for OSPF authentication, based on the document to which I'm a co-author. This is a "spare time" project for me so I don't have an ETA. We do have customers who have expressed interest in this enhancement. Regards, Michael _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sat Dec 27 05:35:27 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4178D3A6A85; Sat, 27 Dec 2008 05:35:27 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4613A6A85 for ; Sat, 27 Dec 2008 05:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6xdJe3aKwr4 for ; Sat, 27 Dec 2008 05:35:25 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 46EB03A67E1 for ; Sat, 27 Dec 2008 05:35:25 -0800 (PST) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id mBRDYm0D005047; Sat, 27 Dec 2008 07:34:48 -0600 (CST) Received: from ITDENE2KSM01.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.0/8.14.0) with ESMTP id mBRDYgoM004952; Sat, 27 Dec 2008 07:34:43 -0600 (CST) Received: from qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) by ITDENE2KSM01.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Dec 2008 06:34:42 -0700 Received: from qtdenexhtm21.AD.QINTRA.COM (151.119.91.230) by qtdenexhtm20.AD.QINTRA.COM (151.119.91.229) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 27 Dec 2008 06:34:41 -0700 Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Sat, 27 Dec 2008 06:34:41 -0700 From: "Smith, Donald" To: Michael Barnes , "opsec@ietf.org" Content-Class: urn:content-classes:message Date: Sat, 27 Dec 2008 06:34:37 -0700 Thread-Topic: [OPSEC] FW: minutes part 2 Thread-Index: AcllgRO9jwqkXhYZR0WXB4QUiOvg+gCpp9AXAAAKgXg= Message-ID: <22B4D402-A1C8-4834-B031-A8B213158E8C@mimectl> References: <49518B19.4050803@cisco.com> In-Reply-To: <49518B19.4050803@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.1.240.3 MIME-Version: 1.0 X-OriginalArrivalTime: 27 Dec 2008 13:34:42.0665 (UTC) FILETIME=[DFED3D90:01C96827] Subject: Re: [OPSEC] FW: minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Michael, hopefully that will come with some type of TTL restriction ability (GTSM). Without it the encryption function becomes a good "slow path" dos vector. Donald.Smith@qwest.com Please cc the handlers to keep them all in the loop. ________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Michael Barnes [mjbarnes@cisco.com] Sent: Tuesday, December 23, 2008 6:06 PM To: opsec@ietf.org Subject: [OPSEC] FW: minutes part 2 > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] > On Behalf Of R Atkinson > Sent: Wednesday, December 17, 2008 6.58 AM > To: opsec@ietf.org > Subject: Re: [OPSEC] minutes part 2 > > > Vishwas, > > Can we please get answers to these questions -- which in fact > are entirely on topic for the OPsec WG, since they are all > operational security matters ? > > (Single quotes are from me; double-quotes are from Vishwas' > earlier emails.) > 4: Availability of SHA mechanisms for IGP authentication > > Further, there are no known shipping implementations of > > SHA authentication for any IETF-specified IGP. > > (I don't know of any that are even "in progress".) > >> We know of a few including a big router vendor. :)) > > Which ? How many ? When ? > Are they shipping now or in progress now ? I am working on an enhancement to use HMAC SHA for OSPF authentication, based on the document to which I'm a co-author. This is a "spare time" project for me so I don't have an ETA. We do have customers who have expressed interest in this enhancement. Regards, Michael _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sun Dec 28 00:55:05 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 784A83A6AF3; Sun, 28 Dec 2008 00:55:05 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35AED3A6AF3 for ; Sun, 28 Dec 2008 00:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-X87+j-IJZu for ; Sun, 28 Dec 2008 00:55:03 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 608523A6405 for ; Sun, 28 Dec 2008 00:55:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,291,1228089600"; d="scan'208";a="220516613" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 Dec 2008 08:54:53 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mBS8srtB010292; Sun, 28 Dec 2008 00:54:53 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBS8srr3014534; Sun, 28 Dec 2008 08:54:53 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Dec 2008 00:54:53 -0800 Received: from [10.21.147.221] ([10.21.147.221]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Dec 2008 00:54:52 -0800 Message-ID: <49573EDA.90800@cisco.com> Date: Sun, 28 Dec 2008 00:54:50 -0800 From: Michael Barnes User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: "Smith, Donald" References: <49518B19.4050803@cisco.com> <22B4D402-A1C8-4834-B031-A8B213158E8C@mimectl> In-Reply-To: <22B4D402-A1C8-4834-B031-A8B213158E8C@mimectl> X-OriginalArrivalTime: 28 Dec 2008 08:54:52.0665 (UTC) FILETIME=[F2B84E90:01C968C9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=366; t=1230454493; x=1231318493; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjbarnes@cisco.com; z=From:=20Michael=20Barnes=20 |Subject:=20Re=3A=20[OPSEC]=20FW=3A=20=20minutes=20part=202 |Sender:=20; bh=qxAkHW9dDl4oE7FS48wa90ALDV5rl/H9a5b11oYWdm0=; b=MsDWZL2GgKTFpSbriGniVFFRygz2jS1Ow3ALdQ1ilEjP4BeVLXjx4cPHN5 kYBGQ5crCIObfDaQTrjzlBIEPSoOMTyB0gWxRPqaEOiWmHSa5/wGsUMZm3Nb JFw8z3PTJk; Authentication-Results: sj-dkim-4; header.From=mjbarnes@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "opsec@ietf.org" Subject: Re: [OPSEC] FW: minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Donald, GTSM was implemented some time ago and is already available in some releases. Regards, Michael Smith, Donald wrote: > Michael, hopefully that will come with some type of TTL restriction ability (GTSM). Without it the encryption function becomes a good "slow path" dos vector. > > > Donald.Smith@qwest.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Dec 29 04:44:44 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1AD3A6972; Mon, 29 Dec 2008 04:44:44 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C61083A6972 for ; Mon, 29 Dec 2008 04:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.454 X-Spam-Level: X-Spam-Status: No, score=0.454 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rj8qg0+S48Mr for ; Mon, 29 Dec 2008 04:44:42 -0800 (PST) Received: from web35303.mail.mud.yahoo.com (web35303.mail.mud.yahoo.com [66.163.179.97]) by core3.amsl.com (Postfix) with SMTP id 5A4C63A6874 for ; Mon, 29 Dec 2008 04:44:42 -0800 (PST) Received: (qmail 48716 invoked by uid 60001); 29 Dec 2008 12:44:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=WC+CbgIzsEaTRWT4cFYfTffQPSsqdOUtSEtsZv2t3tQWlNRujeygQ7I4wSx1nu0GKIbLnaiymPw1joPoPXWN5CjsRHHGEW+q46J4qgFHxDS/aJ9Nib6l2lWc2dRzBEVJLF/oUbJiDK71zGabflWv4ONKZ1jgyPdgeeMN09x/2Kw=; X-YMail-OSG: ofK3.H8VM1k2PNGQATBCpTnCuT__jYfgrrz4i9kUff_e8pI16gbHa7lSEscegnOxf_.0ucmZYzyhFJQ85ZAxkW8DA.GpegzWaWe3IWiLDcr0sn66YAx7.kbUq4SxzH4z4k4S_RRKSxGvaCbfMfp6EFxi81jUqClWXjgRj4U_Gj6C1MPo.2sloc2TSFeNkh2O8E3OL_XFC6MyVzl.JGDn6M.Bmdu7 Received: from [79.173.232.43] by web35303.mail.mud.yahoo.com via HTTP; Mon, 29 Dec 2008 04:44:32 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Mon, 29 Dec 2008 04:44:32 -0800 (PST) From: Alaa Al-Din Al-Radhi To: ipv6@ietf.org MIME-Version: 1.0 Message-ID: <291085.48144.qm@web35303.mail.mud.yahoo.com> Cc: geopriv@ietf.org, opsec@ietf.org Subject: [OPSEC] =?utf-8?q?Recent_Predestinations_=E2=80=93_End_Nov_2008?= =?utf-8?q?=2C_Tunisia?= X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1124321654==" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org --===============1124321654== Content-Type: multipart/alternative; boundary="0-780052479-1230554672=:48144" --0-780052479-1230554672=:48144 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear Colleagues / Friends=20 =C2=A0=20 Kind respects and happy New Year=20 =C2=A0=20 Allow me to seize this moment to share with you the attached recent PPTs th= at I have presented (as being hired as an ITU regional consultant) in Tunis= ia lately: =C2=A0 http://www.itu.int/ITU-D/arb/ARO_2008_work/IP-Communications/ =C2=A0 Feel free to disseminate these PPTs to related interested parties. I believ= e firmly in knowledge share.=20 =C2=A0=20 Your comments and notes are kindly appreciated.=20 =C2=A0=20 If I can be of any future help to your mission, that would be my pleasure a= nd honor.=20 =C2=A0=20 All Blessings and respects=20 =C2=A0=20 Alaa Al-Din (Aladdin)=20 Passionate / Advocate of: Internet, Science, technology, innovations and ne= w frontiers.=20 + 962 796347600=20 alradhi2000@yahoo.ca, alaalradhi@hotmail.com=20 =C2=A0=20 http://www.linkedin.com/in/alaaaldinalradhi=C2=A0=20 =C2=A0=20 http://aso.icann.org/elections/radhi.html=20 =C2=A0=20 http://www.pir.org/index.php?db=3Dcontent/Website&tbl=3DAbout_Us&id=3D7#aal= radhi=C2=A0=20 =C2=A0=20 http://akms.org/site_content.aspx?page_key=3Dboard_of_trustees&lang=3Den=C2= =A0=20 =C2=A0=20 http://www.isoc.org/pubpolpillar/governance/igf-hyderabad_ambassadors.shtml= =20 =C2=A0=20 Excellence is never an accident; it=E2=80=99s always the result of high int= ention, sincere effort, intelligent direction, skilful execution and the vi= sion to see obstacles as opportunities=0A=0A=0A ______________________= ____________________________________________=0AGet a sneak peak at messages= with a handy reading pane with All new Yahoo! Mail: http://ca.promos.yahoo= .com/newmail/overview2/ --0-780052479-1230554672=:48144 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Dear Colleagues / Friends=20

 =20

Kind respects and happy New Year= =20

 =20

Allow me to seize this moment to share wi= th you the attached recent PPTs that I have presented (as being hired as an= ITU regional consultant) in Tunisia lately:

 

http://www.itu.int/ITU-D/arb/ARO_2008_work= /IP-Communications/

 

Feel free to disseminate these PPTs to re= lated interested parties. I believe firmly in knowledge share.=20

 =20

Your comments and notes are kindly apprec= iated.=20

 =20

If I can be of any future help to your mi= ssion, that would be my pleasure and honor.=20

 =20

All Blessings and respects=20

 =20

Alaa Al-Din (Aladdin)=20

Passionate / Advocate of: Internet, Scienc= e, technology, innovations and new frontiers.=20

+ 962 796347600

alradhi2000@yahoo.ca= , alaalradhi@hotmail.com=20

 =20

http://www.linkedin.com/in/alaaaldinalradhi<= /A> 

 =20

http://aso.icann.org/elections/radhi.html =

 =20

http://www.pir.org/index.php?db=3Dcontent/Website&tbl=3DAbout_Us&i= d=3D7#aalradhi 

 =20

http://akms= .org/site_content.aspx?page_key=3Dboard_of_trustees&lang=3Den=  

 =20

http://www.i= soc.org/pubpolpillar/governance/igf-hyderabad_ambassadors.shtml

 =20

Excellence is never an accident; it=E2=80= =99s always the result of high intention, sincere effort, intelligent direc= tion, skilful execution and the vision to see obstacles as opportunities


=0A
All new Yahoo! Mail - Ge= t a sneak peak at messages with a handy reading pane. --0-780052479-1230554672=:48144-- --===============1124321654== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec --===============1124321654==-- From opsec-bounces@ietf.org Mon Dec 29 09:59:11 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C1E3A6C56; Mon, 29 Dec 2008 09:59:11 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF693A6C56 for ; Mon, 29 Dec 2008 09:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BaM2xRXvrWr for ; Mon, 29 Dec 2008 09:59:09 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 058D83A677C for ; Mon, 29 Dec 2008 09:59:08 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so2711914qwe.31 for ; Mon, 29 Dec 2008 09:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=xxdVmhNHSWk0qnCC1A+b0lD8BPLgjKyyWAzA8xyHvxY=; b=p958ZNlvtapoXNIndoNE1HsLokgwQUjf5ha/BJc+aMrFsITm95FUp8Gie/NKb7CwC+ 7ZQ3fFGBOtJf98V0ePes5ShELAp4bkoLs27IPZwgD7QSu0CpP4b4wMRIojtvNJnASKdr z3Z8wEU+rj7eIfBPbbrhedLiXKgEypCMWK0Qg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=ABDRQkENlHhkIEV/BTccyKLfwPC8TK0kJ/KZDALnvC9CA1Wr8XDTputBDxRlg33VAp eDql4ezyKdTjb21jhiE9e9di0AfjjwwwZD8Ta58Sz1YP1osz4O46Ga3Puadk/1UxUzZT moAy8/C5kPtRfjwdF5R+wpGN5iVXgTjtQ/I+4= Received: by 10.214.129.16 with SMTP id b16mr5109680qad.39.1230573537110; Mon, 29 Dec 2008 09:58:57 -0800 (PST) Received: from ?10.30.20.71? (pool-72-84-80-181.nrflva.fios.verizon.net [72.84.80.181]) by mx.google.com with ESMTPS id 9sm343022yws.44.2008.12.29.09.58.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Dec 2008 09:58:56 -0800 (PST) Message-Id: <4070E95B-4E30-4B1F-90F1-B20F67EDEDFF@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812231556t73e24f17m9d52862672b22dc5@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 29 Dec 2008 12:58:45 -0500 References: <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <77ead0ec0812231006u55443dacn1731f51a8e922b62@mail.gmail.com> <8CA72870-DEB9-4979-8478-ED5467AF3DD3@gmail.com> <77ead0ec0812231556t73e24f17m9d52862672b22dc5@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 23 Dec 2008, at 18:56, Vishwas Manral wrote: > "Regardless of use, NIST encourages application and protocol designers > to use the SHA-2 family of hash functions for all new applications and > protocols." That is a policy statement, not a claim that it is safe to use. NIST are required by US law to recommend *something* for US agencies to use, and SHA-2 has the largest raw key size of NIST's (currently quite limited) choices. However, NIST ARE working to deprecate SHA -- visible via the process described on their web site. That process is entirely analogue to the process NIST used to replace DES with AES -- public submission period, public review period, and so forth. >> "The SHA-2 family of hash functions may be used by Federal agencies >> for all applications using secure hash algorithms." >> >> "Federal agencies should stop using SHA-1 for digital signatures, >> digital time stamping, and other applications that require >> collision resistance as soon as practical..." > I am sorry to use the term safe. My intent was to state that SHA-1 has > been mandated to be not used for particular applications, while .SHA-2 > family is encouraged for use by protocol designers. > > Are we on the same page regarding this or not? I don't know what your view is. NIST says that there are "serious attacks" on the SHA family and NIST is actively working to deprecate the SHA family (replacing it with something else). So there is NOT scientific reason to believe that the SHA family is stronger *as used in IGP authentication* than some other algorithm -- nor is there reason to believe some other algorithm is stronger than SHA given what we know right now. What would help here is a scientific paper comparing A and B formally and reaching some conclusion(s), a refereed openly published paper that everyone here can read. Cheers, Ran rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Dec 29 10:03:04 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD3D828C270; Mon, 29 Dec 2008 10:03:04 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B99A28C270 for ; Mon, 29 Dec 2008 10:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4i6uubPyvaFN for ; Mon, 29 Dec 2008 10:03:02 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id A54C428C262 for ; Mon, 29 Dec 2008 10:03:02 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so2712998qwe.31 for ; Mon, 29 Dec 2008 10:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=JbCCYoHRBhzCOgfGrN7reNV+fo+VNnCQPS59oPUJOe4=; b=DBJ7WqzMdEPodgKivxOKdtaDFITpfs3uFn7qTOXuNKtuEQXTagPwescEWyvjOrouxk zLjrFPfrZ05NXWNeHAYxz9BeXNSQapg1VCzybb40wGeSUj+ZF8G71Jc07x8h1gLewmNY iltBr7MX088vfGi0JhY7R7O7hJdOGdHuGChMQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=WBjdx/cNRuqxVCHvuikmm6AfK4hK2BQoT+wi38kScizzGg8C2XIKuBFgCKi46/gmoK cWmDJHvbArhz9mGnUMthPWe2Id+x7olgDvyoeiyDWciOo6TLO3v8xfi5q+3mEqEwbj0m Cfd/bhT/f9hzP+Y1lW2r0PQQIla06HGMmYUhs= Received: by 10.214.80.1 with SMTP id d1mr11389269qab.288.1230573771390; Mon, 29 Dec 2008 10:02:51 -0800 (PST) Received: from ?10.30.20.71? (pool-72-84-80-181.nrflva.fios.verizon.net [72.84.80.181]) by mx.google.com with ESMTPS id 6sm4353129ywi.46.2008.12.29.10.02.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Dec 2008 10:02:50 -0800 (PST) Message-Id: <150709D1-CD36-474E-98F9-5FC363FBBD10@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812231600vbd7c8fejd3a72a67b200185c@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 29 Dec 2008 13:02:49 -0500 References: <77ead0ec0812161118l3ca37732m541deb4c716a8f42@mail.gmail.com> <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <77ead0ec0812231021g2a9b84a5q70533d5e0d74f7b4@mail.gmail.com> <4A20D9A3-5A0B-4A11-AF7E-0773E0519B23@gmail.com> <77ead0ec0812231600vbd7c8fejd3a72a67b200185c@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 23 Dec 2008, at 19:00, Vishwas Manral wrote: > So are you stating that the current known vulnerabilities affect the > HMAC constructs too? I'm claiming there is no clear scientific evidence that any one approach is stronger than another. There is data causing anxiety about each of the underlying algorithms. So far as I can tell from a literature survey, there are no published attacks on Keyed-MD5 or on HMAC-MD5 or on HMAC-SHA -- but that absence of published attacks does not provide any scientific reason to prefer any one of those over any other of those. If someone has a refereed openly published paper evaluating these scientifically, please share the paper (or a pointer to the paper) here so everyone can read it. Absent such a paper, the data collectively gives cause for concern, but does not obviously support one choice over another *on scientific grounds*. Cheers, Ran _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Dec 29 10:08:55 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A37E28C292; Mon, 29 Dec 2008 10:08:55 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF30628C28C for ; Mon, 29 Dec 2008 10:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFLqvWCTAlkV for ; Mon, 29 Dec 2008 10:08:52 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id ABC2C28C285 for ; Mon, 29 Dec 2008 10:08:52 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so2334389ywj.49 for ; Mon, 29 Dec 2008 10:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=N3X8acN5UiF4n+TVqoGnbLhau8UMceZiQ2daOFxf19c=; b=oW10xTH+v+V03jY+zjTf0lJtAgk+lrXqNqTfDVKfJNUwDI313CXzTGz5rod44TwF1u srvEsdhM5fzLbcNiTK+7bjLhS/SgOQaeQypvGqbALr0gN2kdUac/2W+D4/+muJK84NTo aJa5avfSiU2dvuP1gCzq07QrwGLPK9cIWxedg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=A1rJBkjosAXqxFbX9x6G7herwYysdTdB0vlwnCQrBCoRbemniWoWjd1G1W+rZWXcZo Y3+0cIJnJn8Z770tB6d8MKEn5GSit9Daj6hWfGkws4aIHUT2la07HkWkOKdAh/hW4eZY gLAEplDNckxwxqdVveDFJPSw1K1FaN+r3DgI0= Received: by 10.150.96.10 with SMTP id t10mr13906936ybb.128.1230574121992; Mon, 29 Dec 2008 10:08:41 -0800 (PST) Received: from ?10.30.20.71? (pool-72-84-80-181.nrflva.fios.verizon.net [72.84.80.181]) by mx.google.com with ESMTPS id h27sm19688819elf.16.2008.12.29.10.08.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Dec 2008 10:08:39 -0800 (PST) Message-Id: From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812231642me00ebceue465f19183039492@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 29 Dec 2008 13:08:31 -0500 References: <0C823E84-78EE-4234-9AD8-20688B0F8F55@gmail.com> <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <77ead0ec0812231021g2a9b84a5q70533d5e0d74f7b4@mail.gmail.com> <4A20D9A3-5A0B-4A11-AF7E-0773E0519B23@gmail.com> <77ead0ec0812231600vbd7c8fejd3a72a67b200185c@mail.gmail.com> <77ead0ec0812231642me00ebceue465f19183039492@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 23 Dec 2008, at 19:42, Vishwas Manral wrote: > "After 2010, Federal agencies may use SHA-1 only for the following > applications: hash-based message authentication codes (HMACs); key > derivation functions (KDFs); and random number generators (RNGs). " > > So it seems in NIST view atleast SHA-1 with HMAC constructs is not > affected to warrant a reccomendation to stop its use like for the > other case. Again, NIST by law is required to recommend something. NIST only recommends NIST algorithms, which is why they've kicked off the process to deprecate SHA and select something else for their secure hashing. The above quote is statement of policy, about what Federal agencies may use in which situations. It is not a claim that any of those are "safe to use". Separately that quote does not support any claim that SHA is stronger (or weaker) than some other algorithm in any particular mode of operation. Again, if you have an actual scientific referred openly published paper comparing A and B, then please share it. Until such a paper appears, we don't have the data to make a scientific evaluation of which of several options might be better or worse. In any event, the IETF is global and is supposed to operate based on science, not on the national policy of one country. Cheers, Ran _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Dec 29 13:16:54 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0673E3A6C6B; Mon, 29 Dec 2008 13:16:54 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21EE328C269 for ; Mon, 29 Dec 2008 13:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqKCIrdkKIjB for ; Mon, 29 Dec 2008 13:16:51 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id C37543A6C6A for ; Mon, 29 Dec 2008 13:16:50 -0800 (PST) Received: by bwz14 with SMTP id 14so16660136bwz.13 for ; Mon, 29 Dec 2008 13:16:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=csTIO/ke/0PYtd32X2zc0SNJz9p6eNoebijZ+oUXIOE=; b=E1za/Qh+IS9PRhkBCCOIgzhuVtcu4tgO0dJQagNWLhY6XvFa3nnWMdI3StluKTafM6 7fDRkvGT8OJ88v9+ncySS8gxjIUN+s5LA8yZd/2g/juS3t03g/rpJ5fYqBnzyC+dia/p Sfp8q6rRJmHQgT1SZGah51P+GX4ZoRKICuDtA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=K3UuJUEEKDW7zjBwT6JXID1vnv+zq4I4BDSRAaqQN6oHafCyPvhom5zxtGnITqjNsb SGBG+pV6aNpnzReM8xqNBDJqYlZuRJwvXwarKj6BbXd7zC1YsCvDeqaPtynjz6Xb3WTi M5FOth2st23EDvlkf98EChoujJcVfGWsHgy2w= Received: by 10.180.251.15 with SMTP id y15mr5352228bkh.106.1230585399533; Mon, 29 Dec 2008 13:16:39 -0800 (PST) Received: by 10.180.209.3 with HTTP; Mon, 29 Dec 2008 13:16:39 -0800 (PST) Message-ID: <77ead0ec0812291316h75c87da3i190cb23996e09a10@mail.gmail.com> Date: Mon, 29 Dec 2008 13:16:39 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <4070E95B-4E30-4B1F-90F1-B20F67EDEDFF@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <77ead0ec0812231006u55443dacn1731f51a8e922b62@mail.gmail.com> <8CA72870-DEB9-4979-8478-ED5467AF3DD3@gmail.com> <77ead0ec0812231556t73e24f17m9d52862672b22dc5@mail.gmail.com> <4070E95B-4E30-4B1F-90F1-B20F67EDEDFF@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, Great to hear you back. Hope you had a good holiday. I will reply to your earlier questions about the SHA algorithm as well as the other mails you have replied to. I have worked over the questions you raised as well as talked to cryptographers as well as the AD's for the same. > On 23 Dec 2008, at 18:56, Vishwas Manral wrote: >> >> "Regardless of use, NIST encourages application and protocol designers >> to use the SHA-2 family of hash functions for all new applications and >> protocols." > > That is a policy statement, not a claim that it is safe to use. > > NIST are required by US law to recommend *something* for > US agencies to use, and SHA-2 has the largest raw key size > of NIST's (currently quite limited) choices. That is good. So we agree that NIST atleast encourages the protocol designers to use the algorithms. :) We probably also agree that there is cutomer request for the use of the SHA algorithms as has been brought out by others too. I have been following the NIST development of the new protocol and it is very well known inside the community that any new algorithm to replace SHA will be deployable only 10 years or so later. So I agree its a good aim to have to use the algorithms that come out of the selection process, the process itself may take a few years to get through. Regarding the talk of SHA algorithm having issues are correct however after talking to cryptographers who have evaluated the current attacks - it seems clear to them that MD5 strength is considerably lesser than the SHA algorithm strengths. I will send you the details in another mail. I have already shared the same with the WG chair. It also seems clear from talks with the AD's that MD5 is not recommended in any form for any cryptographic use - it is however still not the case for SHA algorithm. Thanks, Vishwas > However, NIST ARE working to deprecate SHA -- visible via > the process described on their web site. That process > is entirely analogue to the process NIST used to replace > DES with AES -- public submission period, public review > period, and so forth. > >>> "The SHA-2 family of hash functions may be used by Federal agencies >>> for all applications using secure hash algorithms." >>> >>> "Federal agencies should stop using SHA-1 for digital signatures, >>> digital time stamping, and other applications that require >>> collision resistance as soon as practical..." >> >> I am sorry to use the term safe. My intent was to state that SHA-1 has >> been mandated to be not used for particular applications, while .SHA-2 >> family is encouraged for use by protocol designers. >> >> Are we on the same page regarding this or not? > > I don't know what your view is. > > NIST says that there are "serious attacks" on the > SHA family and NIST is actively working to deprecate > the SHA family (replacing it with something else). > > So there is NOT scientific reason to believe that the > SHA family is stronger *as used in IGP authentication* > than some other algorithm -- nor is there reason to > believe some other algorithm is stronger than SHA given > what we know right now. > > What would help here is a scientific paper comparing > A and B formally and reaching some conclusion(s), > a refereed openly published paper that everyone here > can read. > > Cheers, > > Ran > rja@extremenetworks.com > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Dec 29 13:55:03 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAD5C3A67FD; Mon, 29 Dec 2008 13:55:03 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA193A677C for ; Mon, 29 Dec 2008 13:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLYEGMqBwfkv for ; Mon, 29 Dec 2008 13:55:01 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 61EF93A67FD for ; Mon, 29 Dec 2008 13:55:01 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so2776203qwe.31 for ; Mon, 29 Dec 2008 13:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=mLeVS4sfY0f5zi4VaYPe1o6NWevz0Iy5TwC9cQ3+vS4=; b=g5BkC2G1kxoNAwb6grbNL2kHJPpXmhEchdhRJVv8YgzOJwcL2W+u09EswJiL/Xhvbg 7IvXvZhm1qcZWX7C0Pc11vb14v6wK+grpAtdPmD79fKfhuU7z6G5EXTz5Ul5HoC+XFjW mSvEKlvG5qMVdmzsDraolOQIzAY5Fo1r/GD/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=IbUWMLkunJsj8AQtOyPOBoeVH/R+EhYeA5TCdBkrzfUn9Qj6SQzSOM3uNQjmDAS/mH QDMfmKbykHpLa6HG/KSCwKb3V5rCFkvy/q87/qkneiTLU41JQ3aNty7ooVKrypPS88uk iYCpoKZG+V0m/IZ4UtfKgUsPU2AAShm2SMC74= Received: by 10.214.114.10 with SMTP id m10mr11743929qac.306.1230587689613; Mon, 29 Dec 2008 13:54:49 -0800 (PST) Received: from ?10.30.20.71? (pool-72-84-80-181.nrflva.fios.verizon.net [72.84.80.181]) by mx.google.com with ESMTPS id 7sm8855154ywo.20.2008.12.29.13.54.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Dec 2008 13:54:49 -0800 (PST) Message-Id: <104A40DD-D2FB-48F2-A5D2-28C0E4ADA663@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812291316h75c87da3i190cb23996e09a10@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 29 Dec 2008 16:54:44 -0500 References: <77ead0ec0812161616r5cc782c5j69415f75d4aa82bb@mail.gmail.com> <7EBC9C5C-EDF9-4CDD-8E1B-B9D05656ACAA@gmail.com> <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <77ead0ec0812231006u55443dacn1731f51a8e922b62@mail.gmail.com> <8CA72870-DEB9-4979-8478-ED5467AF3DD3@gmail.com> <77ead0ec0812231556t73e24f17m9d52862672b22dc5@mail.gmail.com> <4070E95B-4E30-4B1F-90F1-B20F67EDEDFF@gmail.com> <77ead0ec0812291316h75c87da3i190cb23996e09a10@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 29 Dec 2008, at 16:16, Vishwas Manral wrote: > That is good. So we agree that NIST atleast encourages the protocol > designers to use the algorithms. :) Well, your words above are not what I said. NIST prefers SHA-2 over other shorter forms of SHA, probably because NIST (for now) can only recommend SHA (as it is the only NIST hashing algorithm), NIST have to recommend *something*, and SHA-2 has the longest key size. > We probably also agree that there > is cutomer request for the use of the SHA algorithms as has been > brought out by others too. I'm the one who started the whole effort on SHA for IGPs, just as I'm the one who started the whole effort to add cryptographic authentication to IGPs last decade. Having SHA as an option is sensible because it solves a *policy* problem for some US Government users, including some parts of DoD. This was all covered in my past IETF presentations. > I have been following the NIST development of the new protocol and it > is very well known inside the community that any new algorithm to > replace SHA will be deployable only 10 years or so later. I disagree with your 10 year assessment. AES deployed MUCH MUCH more rapidly, after following a similar process for public submission, public review, etc. The IPsec magic number for AES was allocated by IANA shortly after the AES selection was announced by NIST, and there were interoperable implementations of AES-CBC for IPsec ESP shortly after that (even before the I-D appeared, as I recall). > Regarding the talk of SHA algorithm having issues are correct however > after talking to cryptographers who have evaluated the current attacks > - it seems clear to them that MD5 strength is considerably lesser than > the SHA algorithm strengths. I will send you the details in another > mail. I have already shared the same with the WG chair. I've consistently asked for a peer reviewed paper. I like Hugo, but an email containing another person's opinion is not a peer-reviewed paper. Mind, such paper ought to be about the algorithms *in the modes used for IGPs* since the matter at hand is IGPs. If someone has done some formal maths and published it, in some peer reviewed forum, please provide a citation (or URL or something) to that paper so everyone can read it. Hugo publishes from time to time, if he has published on this, it would be helpful if he'd provide the full citation (a URL to the paper would also be nice). > It also seems clear from talks with the AD's that MD5 is not > recommended in any form for any cryptographic use - it is however > still not the case for SHA algorithm. Thanks, but I'll wait for whichever ADs you mean above to speak directly for themselves. (Aside: MD5 was never a NIST algorithm; it isn't a surprise to me that NIST hasn't recommended a non-NIST algorithm for any uses.) Cheers, Ran rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Dec 29 14:01:06 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3DA3A677C; Mon, 29 Dec 2008 14:01:06 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE333A677C for ; Mon, 29 Dec 2008 14:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMFgfMEoHp1H for ; Mon, 29 Dec 2008 14:01:04 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id A778D3A6452 for ; Mon, 29 Dec 2008 14:01:03 -0800 (PST) Received: by bwz14 with SMTP id 14so16699320bwz.13 for ; Mon, 29 Dec 2008 14:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=WLtMUlQmbxwx/NFF5QvFb7Vv0kv6bSSAuA/jdmKEKOc=; b=D5/TsK+JBgj/Rzbn7zuMngxqBiWPj6X0MsbBRTzsGHTflFabdl8NOrIv4Yhk8sY8bd ybR4Toco9toRphB8fL3mZCUifoaAp+X5sQkQXPPclH5W8oKglhAK72wOUav96/t4DAde H6t4vY034MSkRdckDCW+GqUliXTgLKgumPTWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=FocKPNdOVB5Ihr+IFlBuMys2hJZpFHhTuIBirmPwts0wCzW479vjyAU3STeoAAEyRs ZJKkGUhh6eNPsk7T/Ko3Qa2uwtsJbT9oSseICml+gZzx//PwIResm2sPFKKjxmyNcOBv 7aePm0Wtvl5WkRhlvuxZhxZxy8mwrdsjXuKL4= Received: by 10.181.137.13 with SMTP id p13mr5359476bkn.173.1230588051107; Mon, 29 Dec 2008 14:00:51 -0800 (PST) Received: by 10.180.209.3 with HTTP; Mon, 29 Dec 2008 14:00:50 -0800 (PST) Message-ID: <77ead0ec0812291400g5819c929y718683de7fa3ed45@mail.gmail.com> Date: Mon, 29 Dec 2008 14:00:50 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <104A40DD-D2FB-48F2-A5D2-28C0E4ADA663@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <77ead0ec0812231006u55443dacn1731f51a8e922b62@mail.gmail.com> <8CA72870-DEB9-4979-8478-ED5467AF3DD3@gmail.com> <77ead0ec0812231556t73e24f17m9d52862672b22dc5@mail.gmail.com> <4070E95B-4E30-4B1F-90F1-B20F67EDEDFF@gmail.com> <77ead0ec0812291316h75c87da3i190cb23996e09a10@mail.gmail.com> <104A40DD-D2FB-48F2-A5D2-28C0E4ADA663@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, I will deal with the two topics in seperate mails. >> That is good. So we agree that NIST atleast encourages the protocol >> designers to use the algorithms. :) > > Well, your words above are not what I said. >From the NIST site and has been shared earlier with you (I am just quoting what NIST states on its web site which has been updated 2 months back): "Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols." Thanks, Vishwas > NIST prefers SHA-2 over other shorter forms of SHA, > probably because NIST (for now) can only recommend SHA > (as it is the only NIST hashing algorithm), NIST have > to recommend *something*, and SHA-2 has the longest > key size. > >> We probably also agree that there >> is cutomer request for the use of the SHA algorithms as has been >> brought out by others too. > > I'm the one who started the whole effort on SHA for IGPs, > just as I'm the one who started the whole effort to add > cryptographic authentication to IGPs last decade. > Having SHA as an option is sensible because it solves > a *policy* problem for some US Government users, including > some parts of DoD. This was all covered in my past IETF > presentations. > >> I have been following the NIST development of the new protocol and it >> is very well known inside the community that any new algorithm to >> replace SHA will be deployable only 10 years or so later. > > I disagree with your 10 year assessment. AES deployed MUCH > MUCH more rapidly, after following a similar process for > public submission, public review, etc. The IPsec magic > number for AES was allocated by IANA shortly after the AES > selection was announced by NIST, and there were interoperable > implementations of AES-CBC for IPsec ESP shortly after that > (even before the I-D appeared, as I recall). > >> Regarding the talk of SHA algorithm having issues are correct however >> after talking to cryptographers who have evaluated the current attacks >> - it seems clear to them that MD5 strength is considerably lesser than >> the SHA algorithm strengths. I will send you the details in another >> mail. I have already shared the same with the WG chair. > > I've consistently asked for a peer reviewed paper. > I like Hugo, but an email containing another person's > opinion is not a peer-reviewed paper. > > Mind, such paper ought to be about the algorithms *in the modes > used for IGPs* since the matter at hand is IGPs. > > If someone has done some formal maths and published it, > in some peer reviewed forum, please provide a citation > (or URL or something) to that paper so everyone can read it. > > Hugo publishes from time to time, if he has published on > this, it would be helpful if he'd provide the full > citation (a URL to the paper would also be nice). > >> It also seems clear from talks with the AD's that MD5 is not >> recommended in any form for any cryptographic use - it is however >> still not the case for SHA algorithm. > > Thanks, but I'll wait for whichever ADs you mean above > to speak directly for themselves. > > (Aside: MD5 was never a NIST algorithm; it isn't a surprise > to me that NIST hasn't recommended a non-NIST algorithm > for any uses.) > > Cheers, > > Ran > rja@extremenetworks.com > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Dec 29 14:09:09 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F393A6922; Mon, 29 Dec 2008 14:09:09 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC6043A691F for ; Mon, 29 Dec 2008 14:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sls-7bUmRc4 for ; Mon, 29 Dec 2008 14:09:06 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 29C803A6452 for ; Mon, 29 Dec 2008 14:09:05 -0800 (PST) Received: by bwz14 with SMTP id 14so16705723bwz.13 for ; Mon, 29 Dec 2008 14:08:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Dw3W+sTb/rDx+nbZ2HfRIf5tStQn0qObyHJIEZo3HN8=; b=rmUs/0bO0f6h+M71mrOYpW0212axSl1fhoUgzk6fyVy3XEKWJvk3eqclZdGZfEtCvZ MbVpSoU7AM/Ebr4AajIjRYxKOqIh77UZfwqac++6gwn6rJ9HuJu+5O7/56NeuVpt3dAW Db4Wg8wJLAtruaYYut20jT1rKwU6WMnJfsSvg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=tCMjfg9a9aF9Gp4ibeE7bKycKPMj3u8CmyvjDTmdz9X4b1sigJHTda+JDY6PdXIRSB HnBTKUierV4DP0/THLfwdQKA3OhNTZjJGnyzJDN+OkoAD4wtH/beVWNjnJ/dpaahVnwP ULpgW+KGRbVggftu3dOMcZ04ne/QARMkIiDDA= Received: by 10.180.213.15 with SMTP id l15mr4413893bkg.115.1230588533811; Mon, 29 Dec 2008 14:08:53 -0800 (PST) Received: by 10.180.209.3 with HTTP; Mon, 29 Dec 2008 14:08:53 -0800 (PST) Message-ID: <77ead0ec0812291408h434aae6j4e5ee3e50d32bec9@mail.gmail.com> Date: Mon, 29 Dec 2008 14:08:53 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <104A40DD-D2FB-48F2-A5D2-28C0E4ADA663@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <77ead0ec0812231006u55443dacn1731f51a8e922b62@mail.gmail.com> <8CA72870-DEB9-4979-8478-ED5467AF3DD3@gmail.com> <77ead0ec0812231556t73e24f17m9d52862672b22dc5@mail.gmail.com> <4070E95B-4E30-4B1F-90F1-B20F67EDEDFF@gmail.com> <77ead0ec0812291316h75c87da3i190cb23996e09a10@mail.gmail.com> <104A40DD-D2FB-48F2-A5D2-28C0E4ADA663@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, It was really nice to have the discussion with you!!! It helped me really look at and delve deeper based on the recent attacks on SHA-1 which I had anyway taken for granted would not make SHA-1 as weak as MD5. >> I have been following the NIST development of the new protocol and it >> is very well known inside the community that any new algorithm to >> replace SHA will be deployable only 10 years or so later. > > I disagree with your 10 year assessment. It is not my assesment. That is what William Burr from NIST has stated: "SHA-3 is not going to be available, realistically, for another decade, if you look how long it is going to take us to pick it and how long it will take to make its way into products, well, we have been telling people not to wait on SHA-3" I agree AES took about 9 years to be mandated in say the IPsec RFC (so a bit lesser than 10 years). Thanks, Vishwas > AES deployed MUCH > MUCH more rapidly, after following a similar process for > public submission, public review, etc. The IPsec magic > number for AES was allocated by IANA shortly after the AES > selection was announced by NIST, and there were interoperable > implementations of AES-CBC for IPsec ESP shortly after that > (even before the I-D appeared, as I recall). > >> Regarding the talk of SHA algorithm having issues are correct however >> after talking to cryptographers who have evaluated the current attacks >> - it seems clear to them that MD5 strength is considerably lesser than >> the SHA algorithm strengths. I will send you the details in another >> mail. I have already shared the same with the WG chair. > > I've consistently asked for a peer reviewed paper. > I like Hugo, but an email containing another person's > opinion is not a peer-reviewed paper. > > Mind, such paper ought to be about the algorithms *in the modes > used for IGPs* since the matter at hand is IGPs. > > If someone has done some formal maths and published it, > in some peer reviewed forum, please provide a citation > (or URL or something) to that paper so everyone can read it. > > Hugo publishes from time to time, if he has published on > this, it would be helpful if he'd provide the full > citation (a URL to the paper would also be nice). > >> It also seems clear from talks with the AD's that MD5 is not >> recommended in any form for any cryptographic use - it is however >> still not the case for SHA algorithm. > > Thanks, but I'll wait for whichever ADs you mean above > to speak directly for themselves. > > (Aside: MD5 was never a NIST algorithm; it isn't a surprise > to me that NIST hasn't recommended a non-NIST algorithm > for any uses.) > > Cheers, > > Ran > rja@extremenetworks.com > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Dec 29 14:15:35 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC3B3A67D0; Mon, 29 Dec 2008 14:15:35 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DAF33A67D0 for ; Mon, 29 Dec 2008 14:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c30U9Wz1Kxar for ; Mon, 29 Dec 2008 14:15:33 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id D65C13A6452 for ; Mon, 29 Dec 2008 14:15:32 -0800 (PST) Received: by bwz14 with SMTP id 14so16710500bwz.13 for ; Mon, 29 Dec 2008 14:15:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=OyKMKAMN/OsdTgDCtMH2oUWbIHvobW2kJCQrDLyuzbo=; b=x9LbVcCbtKoWBjwhj7DV3rF/p8D3Ds8Naf3OrgCdFOI8ZJ8mjDD5XiBcxVCFU5nuU3 g40UnonBIJYR771T6QU4/qpRByafUA4J60K6lv7m5EYkYBBMEs6LPW7sSjH6SIalrypo QTG5FIwq5I+3ITlczDcJezcSiU5Nn4n+2nFc8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=wMj3iLh/03NhHHUwABR5q5ffA0swcdTVpu872jigGPEC+WkNuNCubXDoxnZh2lRbIX oCswq17hmjJBQmx49SAj+tL8WsN9S5wa9ErAPz0Gg2iA56QPgUB//X7GYgL4D4+HLgaY RsUo9QkAdl8Qiscpmo+t/L5csYs7khClEASqc= Received: by 10.180.203.3 with SMTP id a3mr5362313bkg.146.1230588921490; Mon, 29 Dec 2008 14:15:21 -0800 (PST) Received: by 10.180.209.3 with HTTP; Mon, 29 Dec 2008 14:15:20 -0800 (PST) Message-ID: <77ead0ec0812291415j571f07ebgcc97622496ea65a5@mail.gmail.com> Date: Mon, 29 Dec 2008 14:15:20 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: <104A40DD-D2FB-48F2-A5D2-28C0E4ADA663@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <77ead0ec0812231006u55443dacn1731f51a8e922b62@mail.gmail.com> <8CA72870-DEB9-4979-8478-ED5467AF3DD3@gmail.com> <77ead0ec0812231556t73e24f17m9d52862672b22dc5@mail.gmail.com> <4070E95B-4E30-4B1F-90F1-B20F67EDEDFF@gmail.com> <77ead0ec0812291316h75c87da3i190cb23996e09a10@mail.gmail.com> <104A40DD-D2FB-48F2-A5D2-28C0E4ADA663@gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, > I've consistently asked for a peer reviewed paper. > I like Hugo, but an email containing another person's > opinion is not a peer-reviewed paper. I agree you have asked for a peer reviewed paper for the exact use of SHA for IGP's. > Mind, such paper ought to be about the algorithms *in the modes > used for IGPs* since the matter at hand is IGPs. > > If someone has done some formal maths and published it, > in some peer reviewed forum, please provide a citation > (or URL or something) to that paper so everyone can read it. > > Hugo publishes from time to time, if he has published on > this, it would be helpful if he'd provide the full > citation (a URL to the paper would also be nice). It seems you are hinting at a bigger issue here, that the IETF AD's may need to change the policy regarding MD5 vs SHA-1 (for use in any cryptographic function), because even though cryptographers may state that MD5 is stronger than SHA-1 even for secure hashing purposes, it may not necessarily be true. Thanks, Vishwas _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Dec 29 14:22:48 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7928D3A67D0; Mon, 29 Dec 2008 14:22:48 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E01F3A67D0 for ; Mon, 29 Dec 2008 14:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIqvnk-Gowyq for ; Mon, 29 Dec 2008 14:22:47 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 226373A6452 for ; Mon, 29 Dec 2008 14:22:46 -0800 (PST) Received: by bwz14 with SMTP id 14so16715985bwz.13 for ; Mon, 29 Dec 2008 14:22:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=813dkU9Ov3imkmV/ZbLUJHv6n8s+CPHRAhtkeTICGOI=; b=LmNUP6DjN8zP6CzTslpAmnGdVp4gfqkcsGaW1ATh9fDKeXoF656HtB6oSb2fJ+ID4M ClJs4e7oJkan2vollSYYC5PIkP7Qcz6PRw57m24oERzxgzDI49K/bY7o26QV6tr3t2N6 LkTv7mV6v+mnHDRxPtqWkqdrc96Efi8SyIMdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=mBgK0Le/DuFNkBFcRkqR6Bor8tRQRNzy6VqaMzjSu84ho55a9Su4DGuIxg+nNi63Uj H6PjIIQHb8SWh9Y/hZOkWB8e/IeLD9EObTDu1LBxwj35bDnafTOkWOX5LUNOH9H1JscP vmu1GFfX/WsMYJTln1Vz8oGwzUqUtiVv675iQ= Received: by 10.180.253.20 with SMTP id a20mr1002368bki.19.1230589355906; Mon, 29 Dec 2008 14:22:35 -0800 (PST) Received: by 10.180.209.3 with HTTP; Mon, 29 Dec 2008 14:22:35 -0800 (PST) Message-ID: <77ead0ec0812291422w15cc540ey571c1c8e7c26e8ae@mail.gmail.com> Date: Mon, 29 Dec 2008 14:22:35 -0800 From: "Vishwas Manral" To: "opsec wg mailing list" MIME-Version: 1.0 Content-Disposition: inline Subject: [OPSEC] draft-ietf-opsec-routing-protocols-crypto-issues X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi folks, I would want to know your view regarding adding a sub-section as part of the OSPF section about RFC2154 "OSPF with Digital Signatures " to the draft. I have heard a lot fo conflicting views about the same and would want to know your opinion before progressing further on the same. Thanks a lot to Ran for raising this issue. I personally am not sure if we want to add it. Thanks, Vishwas _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Dec 29 14:28:38 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7EFF3A67B3; Mon, 29 Dec 2008 14:28:38 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755153A67B3 for ; Mon, 29 Dec 2008 14:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1zEJx3CeAP3 for ; Mon, 29 Dec 2008 14:28:36 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 6587F3A6452 for ; Mon, 29 Dec 2008 14:28:36 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so2784129qwe.31 for ; Mon, 29 Dec 2008 14:28:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=XobhOWw7+6IvBtlS/U+kOB7+bcc759M+uV9+g8SGcw4=; b=QlbsQu2QDKevrfyCoG2Dt+tvT9ABWkX9wlvrs59dV9tvT3yFv9IPTVzQKQ7VgiuIYG VU0GoLIFOB3reh72x188yArOtAvKio+Td0PjMAItkgdg6UpSFUK3t6AQFfETegadH9P3 Hx5x1wjPPZp8cqx5SILPMbwduI1bodYQSn5Nw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=ds17QqUqOqZ3YXrRjo3ynWcmyNBLTbjgbILsoLoCVoUhDsURMdbVL/8QiyzabU8Hwe /q6nH77y+iln5gXdWSRflg9vVjfg2sXe4fyJF//Vmm7SBug8K8I+jnGbCAiwYV16UOvK f2N47CsYes44izfJeNJcoapm7EqqvN0ZSm0M0= Received: by 10.214.242.13 with SMTP id p13mr11827903qah.75.1230589705064; Mon, 29 Dec 2008 14:28:25 -0800 (PST) Received: from ?10.30.20.71? (pool-72-84-80-181.nrflva.fios.verizon.net [72.84.80.181]) by mx.google.com with ESMTPS id 5sm2067769ywl.1.2008.12.29.14.28.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Dec 2008 14:28:24 -0800 (PST) Message-Id: From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812291400g5819c929y718683de7fa3ed45@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 29 Dec 2008 17:28:23 -0500 References: <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <77ead0ec0812231006u55443dacn1731f51a8e922b62@mail.gmail.com> <8CA72870-DEB9-4979-8478-ED5467AF3DD3@gmail.com> <77ead0ec0812231556t73e24f17m9d52862672b22dc5@mail.gmail.com> <4070E95B-4E30-4B1F-90F1-B20F67EDEDFF@gmail.com> <77ead0ec0812291316h75c87da3i190cb23996e09a10@mail.gmail.com> <104A40DD-D2FB-48F2-A5D2-28C0E4ADA663@gmail.com> <77ead0ec0812291400g5819c929y718683de7fa3ed45@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 29 Dec 2008, at 17:00, Vishwas Manral wrote: > "Regardless of use, NIST encourages application and protocol designers > to use the SHA-2 family of hash functions for all new applications and > protocols." Really, folks can (and likely have) read the whole URL by now. Your quote above continues to be presented out of context. The context of the quote is that SHA-0 and SHA-1 ought not be used, so NIST considers SHA-2 preferable to SHA-0 and SHA-1. As I've *repeatedly* said, this is not surprising. NIST only recommends NIST algorithms. NIST's only hash algorithm at present is SHA. SHA-2 is the form of SHA with the longest key size. NIST has to recommend some NIST algorithm. So the outcome is not a surprise. In the interest of WG list bandwidth, and at the suggestion of private email from some on this list, I will probably start ignoring your notes about this narrow topic -- until you can provide a refereed paper or two. I can't tell if there is a language issue here or something else is going on, but repetition isn't helping the WG make headway. I've also asked Hugo if he might be kind enough to send some citations to relevant refereed papers directly to this list. Then folks here can read and review collectively whatever appears from whomever finds any such papers. > I agree AES took about 9 years to be mandated in > say the IPsec RFC (so a bit lesser than 10 years). You must have misread my note. AES-CBC for IPsec shipped in about 12 months, not 9 years. AES-CBC for ESP shipped well before the RFC was published, as I recall. Oh, and NIST selecting AES took about 4 years (URL below says 1997 to 2000/2001). NIST's web page also says they expect to announce a new hash function in 2012 (URL below). Four years is somewhat less than half of "10 years" from now. Yours, Ran NIST Hash Timeline (includes AES timeline also): _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Dec 29 14:40:16 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53A53A6942; Mon, 29 Dec 2008 14:40:16 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5943A68BA for ; Mon, 29 Dec 2008 14:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgFhh18v7Ync for ; Mon, 29 Dec 2008 14:40:15 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 749C33A6942 for ; Mon, 29 Dec 2008 14:40:14 -0800 (PST) Received: by bwz14 with SMTP id 14so16729144bwz.13 for ; Mon, 29 Dec 2008 14:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=27Qnn17G5ozzyXmOF8L/Knx2Jq6PFPgn82hFVubp2ew=; b=MBFEi23hxVPwWgDUQmmb+dedQoy2OMYo/FfIuOsNzlLFO2VIlINunmUngkesyRem/U Nc4Cb8LX5+qGQRyhfj8oimKLEO13oiSik4VK/UMDnYd9y56goxFvlFxcORb+WEwSlENz eFnQE55PxLxGNiCbr/4jKGKcku6lwS11f5pfk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=qI6MiQTHjKcQ8UBpU5bAnsvH1JmZGwtFT+T0YH61h9kCdSdjQzcINvexvflP/C9PQb bPsLyACXFJst6EwvzFUThLLrYw/+11T943BSxxFIr2Dw5GG9IF7HwAH/CDA/h+apTTCM U40H3ORGI2QZGIi4pYZ3wG/f+ZYNF7zGuqe/U= Received: by 10.181.146.11 with SMTP id y11mr5380612bkn.5.1230590402466; Mon, 29 Dec 2008 14:40:02 -0800 (PST) Received: by 10.180.209.3 with HTTP; Mon, 29 Dec 2008 14:40:02 -0800 (PST) Message-ID: <77ead0ec0812291440v707b96aaj178a5cb311faa6f5@mail.gmail.com> Date: Mon, 29 Dec 2008 14:40:02 -0800 From: "Vishwas Manral" To: "R Atkinson" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <77ead0ec0812231006u55443dacn1731f51a8e922b62@mail.gmail.com> <8CA72870-DEB9-4979-8478-ED5467AF3DD3@gmail.com> <77ead0ec0812231556t73e24f17m9d52862672b22dc5@mail.gmail.com> <4070E95B-4E30-4B1F-90F1-B20F67EDEDFF@gmail.com> <77ead0ec0812291316h75c87da3i190cb23996e09a10@mail.gmail.com> <104A40DD-D2FB-48F2-A5D2-28C0E4ADA663@gmail.com> <77ead0ec0812291400g5819c929y718683de7fa3ed45@mail.gmail.com> Cc: opsec@ietf.org Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Ran, I am sorry if you are finding issues with my language. >> I agree AES took about 9 years to be mandated in >> say the IPsec RFC (so a bit lesser than 10 years). > > You must have misread my note. AES-CBC for IPsec shipped > in about 12 months, not 9 years. AES-CBC for ESP shipped > well before the RFC was published, as I recall. > > Oh, and NIST selecting AES took about 4 years (URL below > says 1997 to 2000/2001). > > NIST's web page also says they expect to announce a new > hash function in 2012 (URL below). Four years is somewhat > less than half of "10 years" from now. This is great. Yes announcing an algorithm and actually seeing it in the field is different. I have given you a quote from folks in NIST itself (which does not talk about announcement of the chosen algorithm but about actually finding the algorithms in the field). May be there was some gap in the language again. I have not imagined/ concoted the time lines myself. It however is again based on a particular opinion and may not necessarily be correct. Regarding the cryptographic algorithms, I think we need to look at the issue at a bigger level than just this list. Thanks for raising the issues. Thanks again, Vishwas > > > NIST Hash Timeline (includes AES timeline also): > > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Dec 29 14:45:54 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40CD33A69CE; Mon, 29 Dec 2008 14:45:54 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED97A3A69CE for ; Mon, 29 Dec 2008 14:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9qTg4kJx4rC for ; Mon, 29 Dec 2008 14:45:52 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 0DA603A69AD for ; Mon, 29 Dec 2008 14:45:51 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so2369045ywj.49 for ; Mon, 29 Dec 2008 14:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=clDF3gt5CRv5A3zl/MeaDJQu/gtVlDfz1d5dehDMX8A=; b=BXmW+JxaJnnJDjHH5p5PimBQZXc1V6BF1dGmNM2SAnWSrbgnfjbhCU4WMCZHezmwdV q4Qv1pHnNIzenPxb77jS3UNHSTPjx0+MlGDGgPP2ebXuO2RWK79z7tFSie50veGOZW5P BeIoTIhpx1yMJGp6u5tadI2XFSCnDjx1GqSK8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=Fp6ogqcJvXKaxNL9Z3T6O9wPqkTroFKNHxXcXDxyrVmIl5ICs936qQkaYFPOc2ucgu ZysYkYzwoNj9UmEwuATcoaP+tW7yPBW8NJwJa0yzIHIq04o0aGuKCewc0b69AbMltxyF 2PdWnnha/IH+0cItE3pWO01zt48rOFUqwRzok= Received: by 10.151.46.3 with SMTP id y3mr18172145ybj.188.1230590740748; Mon, 29 Dec 2008 14:45:40 -0800 (PST) Received: from ?10.30.20.71? (pool-72-84-80-181.nrflva.fios.verizon.net [72.84.80.181]) by mx.google.com with ESMTPS id u25sm17086894ele.15.2008.12.29.14.45.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Dec 2008 14:45:40 -0800 (PST) Message-Id: <5FB464AF-5A78-4CC4-8255-3D61327D058B@gmail.com> From: R Atkinson To: opsec@ietf.org In-Reply-To: <77ead0ec0812291415j571f07ebgcc97622496ea65a5@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 29 Dec 2008 17:45:39 -0500 References: <494D48B6.9090302@bogus.com> <77ead0ec0812222113m28f91093ke6512a5d7a287b0c@mail.gmail.com> <1D5F3F5F-4357-4E25-BEDE-35300949EDB8@gmail.com> <77ead0ec0812231006u55443dacn1731f51a8e922b62@mail.gmail.com> <8CA72870-DEB9-4979-8478-ED5467AF3DD3@gmail.com> <77ead0ec0812231556t73e24f17m9d52862672b22dc5@mail.gmail.com> <4070E95B-4E30-4B1F-90F1-B20F67EDEDFF@gmail.com> <77ead0ec0812291316h75c87da3i190cb23996e09a10@mail.gmail.com> <104A40DD-D2FB-48F2-A5D2-28C0E4ADA663@gmail.com> <77ead0ec0812291415j571f07ebgcc97622496ea65a5@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] minutes part 2 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 29 Dec 2008, at 17:15, Vishwas Manral wrote: > It seems you are hinting at a bigger issue here, Please do not twist my words. (Repetition of my prior comments for the Nth time omitted here to conserve bandwidth. :-) Yours, Ran rja@extremenetworks.com _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Dec 29 15:44:30 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79B5928C26C; Mon, 29 Dec 2008 15:44:30 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C60DC28C26C for ; Mon, 29 Dec 2008 15:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eym8yi720n5 for ; Mon, 29 Dec 2008 15:44:28 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by core3.amsl.com (Postfix) with ESMTP id C85603A69CE for ; Mon, 29 Dec 2008 15:44:27 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w1so2552665mue.9 for ; Mon, 29 Dec 2008 15:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=I8yAcBv4MgMn2aevbwEeoNwNotfIL6wXaJWCzeU3MnQ=; b=UN0GSM4iIvst6NkNVtdkRrYg9iT+LfZFw6+aEqfasfM0WeJctpWmJXUSIkzePVlq2C x4fpXA4SNy4Mhln4Fovc3avxGcir6KvkQB9c+lGHVZ5g5214M0qLplF2tw3yaau3VjLO NXVL2qXE0FuQ/AmqtbrYixcG5W0KbLOwCQKFI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=kDl60CVEXVWzDOb/WSViMX/OxZ3RFGPDVKv70GTWisDDVeQHR6ulCVxOUu5z3klQZT voc4S6LQX0o+kx8q8gAzYrT5ZYwmob51sK4KCQYHCHKM9zGcLZqHLHxJUwsspeUM9u8W 1S2oxHMLAncBNf95jR1+GUBNxsH2l/yAn7LWA= Received: by 10.103.238.4 with SMTP id p4mr5059262mur.68.1230594256472; Mon, 29 Dec 2008 15:44:16 -0800 (PST) Received: by 10.103.160.12 with HTTP; Mon, 29 Dec 2008 15:44:16 -0800 (PST) Message-ID: <92c950310812291544t1a70b919uf9ce358311a17b64@mail.gmail.com> Date: Tue, 30 Dec 2008 05:14:16 +0530 From: "Glen Kent" To: "Vishwas Manral" , "opsec wg mailing list" In-Reply-To: <77ead0ec0812291422w15cc540ey571c1c8e7c26e8ae@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0812291422w15cc540ey571c1c8e7c26e8ae@mail.gmail.com> Subject: Re: [OPSEC] draft-ietf-opsec-routing-protocols-crypto-issues X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org I agree. Glen. On Tue, Dec 30, 2008 at 3:52 AM, Vishwas Manral wrote: > Hi folks, > > I would want to know your view regarding adding a sub-section as part > of the OSPF section about RFC2154 "OSPF with Digital Signatures > " to the draft. I have heard a lot fo conflicting views about the same > and would want to know your opinion before progressing further on the > same. > > Thanks a lot to Ran for raising this issue. I personally am not sure > if we want to add it. > > Thanks, > Vishwas > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 30 17:33:04 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 074A03A68C9; Tue, 30 Dec 2008 17:33:04 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA7F23A68C9 for ; Tue, 30 Dec 2008 17:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KedAZkPUfSQu for ; Tue, 30 Dec 2008 17:33:03 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id A58A33A67AA for ; Tue, 30 Dec 2008 17:33:02 -0800 (PST) Received: by bwz14 with SMTP id 14so17968227bwz.13 for ; Tue, 30 Dec 2008 17:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=urSHkZ3+xkMyruXMYTvFm6sd/9DruFLR1VC+COAZVmw=; b=Zgse56JyQqxiw22nTV/xqOtteIPwA3AV6gTEq8uPoa7FTuK0svh2iEWNAOPQ0qL2tZ UTr+rk5ElP43ZHfCEg+P/JKcPWHrhOWyTHuunT4SxyAnOLJvKoIgOcUGOKF1bcz6TxPa 8NCozw78b530bkgvFRR2GeCAHGZUkF/bIf1J0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=KWFBfpDMCCkpb6qKOdqCiBQQHADsPjirTLNv9WlaEyvI1SGU0nT1Q0//g/i6Ja5aGj u2RkHEMCBHMtNODQ6NCKWQ0I0jWhWQtTilhJpJwoc7xj3RagNot6CJA7lPpjqrnB0sjz nAdaUZkdIl5fugg4B7lwqPNNQKoCLD7lj3HAM= Received: by 10.181.199.11 with SMTP id b11mr5850231bkq.127.1230687170346; Tue, 30 Dec 2008 17:32:50 -0800 (PST) Received: by 10.180.209.3 with HTTP; Tue, 30 Dec 2008 17:32:50 -0800 (PST) Message-ID: <77ead0ec0812301732l120c30c6n6b63e274771274ac@mail.gmail.com> Date: Tue, 30 Dec 2008 17:32:50 -0800 From: "Vishwas Manral" To: "opsec wg mailing list" MIME-Version: 1.0 Content-Disposition: inline Subject: [OPSEC] Further MD5 breaks X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi folks, There is an interesting discussion on the saag list about "Further MD5 breaks: Creating a rogue CA certificate". http://www.ietf.org/mail-archive/web/saag/current/msg02368.html . There are some mails about the relative strengths of SHA related to MD5 in that environment. Thanks, Vishwas _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Dec 30 21:46:23 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3818A3A6A70; Tue, 30 Dec 2008 21:46:23 -0800 (PST) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0639F3A6A70 for ; Tue, 30 Dec 2008 21:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBtNrwKQk4VJ for ; Tue, 30 Dec 2008 21:46:20 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 4C45C3A6918 for ; Tue, 30 Dec 2008 21:46:20 -0800 (PST) Received: from [192.168.11.143] (c-67-171-158-173.hsd1.or.comcast.net [67.171.158.173]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id mBV5k0me017947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Dec 2008 05:46:04 GMT (envelope-from joelja@bogus.com) Message-ID: <495B0715.8060009@bogus.com> Date: Tue, 30 Dec 2008 21:45:57 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: Vishwas Manral References: <77ead0ec0812301732l120c30c6n6b63e274771274ac@mail.gmail.com> In-Reply-To: <77ead0ec0812301732l120c30c6n6b63e274771274ac@mail.gmail.com> X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV 0.94.2/8815/Tue Dec 30 21:57:57 2008 on nagasaki.bogus.com X-Virus-Status: Clean Cc: opsec wg mailing list Subject: Re: [OPSEC] Further MD5 breaks X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hehm I've been waiting for this message to arrive since early this morning. I think the salient point, Which I made before is that if md5 is in the toolbox, someone, somewhere will use it for something inappropriate. Does that affect the problem at hand? Maybe, maybe not. It is possible I believe to create a scenario where the potential for a hash collision is either temporally or practically irrelevant. As a community I think we've been less pro-active than we should have been, but being deliberate is still the order of the day. joel Vishwas Manral wrote: > Hi folks, > > There is an interesting discussion on the saag list about "Further MD5 > breaks: Creating a rogue CA certificate". > > http://www.ietf.org/mail-archive/web/saag/current/msg02368.html . > There are some mails about the relative strengths of SHA related to > MD5 in that environment. > > Thanks, > Vishwas > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec