Re: [RPSEC] [secdir] [OSPF] [sidr] Authentication for OSPFv3

Stephen Kent <kent@bbn.com> Thu, 02 October 2008 16:08 UTC

Return-Path: <rpsec-bounces@ietf.org>
X-Original-To: rpsec-archive@megatron.ietf.org
Delivered-To: ietfarch-rpsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBF343A6A90; Thu, 2 Oct 2008 09:08:43 -0700 (PDT)
X-Original-To: rpsec@core3.amsl.com
Delivered-To: rpsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 465C83A6A8B; Thu, 2 Oct 2008 09:08:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level:
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 qhw3qyAhxffz; Thu, 2 Oct 2008 09:08:42 -0700 (PDT)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 7AF2E3A6A27; Thu, 2 Oct 2008 09:08:42 -0700 (PDT)
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1KlQj8-00079C-DE; Thu, 02 Oct 2008 12:08:30 -0400
Mime-Version: 1.0
Message-Id: <p06240528c50aa0af40bd@[128.89.89.71]>
In-Reply-To: <BAD965BE-053F-4296-B0F7-CF0F2C9C0779@redback.com>
References: <48D96507.4000207@sri.com> <20080929200231.3E5DD3F443@pecan.tislabs.com> <77ead0ec0809291853t63940339xc826b13cf5515176@mail.gmail.com> <C50382B8-74EB-4157-9043-56CB1D3F8594@cisco.com> <BAD965BE-053F-4296-B0F7-CF0F2C9C0779@redback.com>
Date: Thu, 02 Oct 2008 12:08:12 -0400
To: Acee Lindem <acee@redback.com>
From: Stephen Kent <kent@bbn.com>
Cc: msec@ietf.org, tsvwg@ietf.org, OSPF List <ospf@ietf.org>, secdir@mit.edu, rpsec@ietf.org, David Ward <dward@cisco.com>, sidr@ietf.org, Ross Callon <rcallon@juniper.net>
Subject: Re: [RPSEC] [secdir] [OSPF] [sidr] Authentication for OSPFv3
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Protocol Security Requirements <rpsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/rpsec>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: rpsec-bounces@ietf.org
Errors-To: rpsec-bounces@ietf.org

At 11:08 AM -0400 9/30/08, Acee Lindem wrote:
>One thing to take into consideration is that the outcome of our KMART 
>BOF was that nobody deploying networks wanted routing infra-structure
>based on a third-part verified certificates.
>Thanks,
>Acee

Acee,

The wording you used here "third-part[y] verified certificates" is 
ambiguous. A cert is validated (or verified) by a relying party, so 
third-party verification could imply having some entity verify  a 
cert on behalf of a relying party, e.g,  what SCVP permits. If, on 
the other hand, you were referring to cert issuance (not 
verification), then it is commonly the case that the cert issuer 
(certification authority) in a PKI is a "third party" in that it is 
not a participant in a communication between two relying parties.  In 
either case, I don't recall hearing specific comments of the form you 
mention.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/rpsec