Re: [secdir] SecDir review of draft-ietf-keyprov-pskc-05
"Philip Hoyer" <phoyer@actividentity.com> Tue, 18 May 2010 13:17 UTC
Return-Path: <phoyer@actividentity.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBEC73A698C; Tue, 18 May 2010 06:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.409
X-Spam-Level:
X-Spam-Status: No, score=0.409 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_50=0.001, HELO_EQ_FR=0.35]
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 zfIsq8URNeF5; Tue, 18 May 2010 06:17:57 -0700 (PDT)
Received: from frhub1.activcard.fr (frhub1.activcard.fr [92.103.229.143]) by core3.amsl.com (Postfix) with ESMTP id 224DF3A69A0; Tue, 18 May 2010 06:15:06 -0700 (PDT)
Received: from sur-corp-ex-02.corp.ad.activcard.com (sur-corp-ex-02.corp.ad.activcard.com [192.168.33.40]) by frhub1.activcard.fr (Postfix) with ESMTP id BDCFF18393A; Tue, 18 May 2010 15:14:57 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 18 May 2010 15:17:50 +0200
Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC4068908EB@sur-corp-ex-02.corp.ad.activcard.com>
In-Reply-To: <4BF115AD.5010400@inrialpes.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: SecDir review of draft-ietf-keyprov-pskc-05
Thread-Index: Acr1qVnRMyhx+GMiSp++tqcZPZHluQA4xe/A
References: <4BDF2F06.2030406@inrialpes.fr> <5BFE9E473DBFC24CA87F18F29B3F0AC406890884@sur-corp-ex-02.corp.ad.activcard.com> <4BF115AD.5010400@inrialpes.fr>
From: Philip Hoyer <phoyer@actividentity.com>
To: Vincent Roca <vincent.roca@inrialpes.fr>
X-Mailman-Approved-At: Tue, 18 May 2010 06:32:05 -0700
Cc: draft-ietf-keyprov-pskc.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] SecDir review of draft-ietf-keyprov-pskc-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 13:17:57 -0000
Vincent, I have changed the draft to encompass your revised wording of point 2 below. Thanks for your help, Philip -----Original Message----- From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] Sent: Monday, May 17, 2010 11:09 AM To: Philip Hoyer Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-keyprov-pskc.all@tools.ietf.org; vincent.roca@inrialpes.fr Subject: Re: SecDir review of draft-ietf-keyprov-pskc-05 Hello Philip, I see we agree on most items (I removed them). Two comments: > 5- section 13.1: > why isn't the IPsec/ESP not considered also as a third > solution to provide the confidentiality, integrity and sender > authentication services? Why do the authors only focus > on PCKS integrated or TLS solutions? It's not clear. > [PH] the authors felt that the usage of the container was intended for > application level interchange of keys. Especially in online scenarios > where TLS is much more prevalent than IPSec. This does not mean that one > could not envisage use of the PSKC over IPsec and hence use IPsec > protection mechanisms. > [VR] I understand. Thanks for the clarification. > 9- section 13.3: it is said: > "A weaker payload authenticity guarantee may be provided by the > transport layer if it is configured to digest each message it > transports." > > Why is this feature necessarily weaker? The source can be > authenticated with the same level of security as if it was > done by the recipient end. > [PH] it is weaker in the sense that the TLS endpoints could differ from > the key provisioning endpoints. So in that sense the signature in the > message would protect it from message sender to receiver. > [VR] Said this way, I fully agree. I suggest you clarify the I-D as well, e.g.: "Authenticity guarantee may be provided by [...]. However, no authenticity verification is possible once [...]. Since the TLS endpoints could differ from the key provisioning endpoints, this solution is weaker than the previous solution that relies on a digital signature of the PSKC." Cheers, Vincent
- [secdir] SecDir review of draft-ietf-keyprov-pskc… Vincent Roca
- Re: [secdir] SecDir review of draft-ietf-keyprov-… Philip Hoyer
- Re: [secdir] SecDir review of draft-ietf-keyprov-… Vincent Roca
- Re: [secdir] SecDir review of draft-ietf-keyprov-… Philip Hoyer