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