[Gen-art] RE: Gen-ART review of draft-martin-ibcs-03
Black_David@emc.com Thu, 05 April 2007 01:00 UTC
Return-path: <gen-art-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGKs-0004QA-QH; Wed, 04 Apr 2007 21:00:22 -0400
Received: from gen-art by megatron.ietf.org with local (Exim 4.43) id 1HZGKs-0004Ou-4O for gen-art-confirm+ok@megatron.ietf.org; Wed, 04 Apr 2007 21:00:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGKr-0004OO-QR for gen-art@ietf.org; Wed, 04 Apr 2007 21:00:21 -0400
Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZGKq-0008QK-El for gen-art@ietf.org; Wed, 04 Apr 2007 21:00:21 -0400
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l3510Hiq009666; Wed, 4 Apr 2007 21:00:17 -0400 (EDT)
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l350xuY4009042; Wed, 4 Apr 2007 21:00:03 -0400 (EDT)
From: Black_David@emc.com
Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 20:59:57 -0400
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 04 Apr 2007 20:59:57 -0400
Message-ID: <F222151D3323874393F83102D614E055068B91D1@CORPUSMX20A.corp.emc.com>
In-Reply-To: <1C01650B36DD3746867EA0B30E3B9819579586@influenza.voltage.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Gen-ART review of draft-martin-ibcs-03
Thread-Index: Acd2LPG7dNbUer4mS5igtGL0dmPHWQA0p9cgAAKOgRA=
References: <F222151D3323874393F83102D614E055068B91B6@CORPUSMX20A.corp.emc.com> <1C01650B36DD3746867EA0B30E3B9819579586@influenza.voltage.com>
To: martin@voltage.com, gen-art@ietf.org, xavier@voltage.com
X-OriginalArrivalTime: 05 Apr 2007 00:59:57.0846 (UTC) FILETIME=[BB003B60:01C7771D]
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.4.4.173834
X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.2 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: lnoll@neoscale.com, Black_David@emc.com
Subject: [Gen-art] RE: Gen-ART review of draft-martin-ibcs-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org
Luther, > First, concerning point [2], it seems that the IPR statement at > > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=821 > > covers this draft. Or do we need to update this for each version of a draft? It looks like that disclosure covers this draft, but the IETF IPR disclosure engine didn't find that disclosure when I asked it about about draft-martin-ibcs-03 - I think I need to file a bug report ;-). In addition, some indication of where this draft stands wrt Certicom's patents would be very useful. > Next, regarding point [3], the algorithms described in this draft are > public-key algorithms and are definitely not stream ciphers. I stand behind point [3], here's a longer explanation and example: At least Section 8.4 and 8.5 perform encryption and decryption by XOR-ing a keystream with the plaintext or ciphertext (Sections 5.4 and 5.5 appear to do likewise, but there are potential mistakes in those sections that make this somewhat unclear). While "stream cipher" may not be a precise term for these constructs, they are at least a stream-cipher-like operating mode for the public key algorithms. In particular, they are subject to <key,IV> reuse concerns that apply to stream ciphers. Specifically, for section 8.4, the actual encryption step for the message m is: y = HashStream(|m|, h') XOR m where h' does not depend on m, so if the same s (effectively an IV) is ever used twice with the same identity and public parameters for different messages that have the same length (e.g., m1 and m2), the HashStream element will be the same, so one can obtain the XOR of the plaintext messages by XORing the corresponding ciphertexts, i.e.: y1 XOR y2 = m1 XOR m2 This is usually considered undesirable, as it tends to leak information about m1 and m2. At a minimum, this needs to be discussed in the security considerations section, even if the countermeasures to prevent this from happening are left to other documents that apply these algorithms to particular contexts. > Are architectural issues, like the restrictions on letting arbitrary > clients decrypt on behalf of an arbitrary identity, more suitable for > other documents? After all, this document just describes two > cryptographic algorithms. Are issues surrounding their applications > better described elsewhere? Yes and no. Let me start with an apology. The following text from my review is not correct: -> It is *very* important to understand that the ability to encrypt -> or decrypt on behalf of an identity is not proof of that identity, -> and hence the mechanisms described in this draft MUST NOT be used -> for authentication purposes, and any identity used with these -> mechanisms MUST be authenticated or verified by other means. With a suitably configured key server including proper use of authentication with key server clients, proof of possession of the private key for an identity could be used as proof of that identity (i.e., authentication), but the configuration restrictions are important. In any case, the above text is wrong as written, and I apologize for that mistake. At the very least, the draft needs an architectural diagram showing the key server and the clients showing which keys flow where for at least one example - that would have saved me from this mistake, and the fact that I made it is a backhanded indication that such a diagram and associated discussion is needed. I think that discussion also needs to bring out the dependence on the key server and authentication to the key server in restricting availability of private keys to their corresponding identities if one intends to use them for authentication. > We will take a closer look at the other comments soon. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Gen-ART review of draft-martin-ibcs-03 Black_David
- [Gen-art] RE: Gen-ART review of draft-martin-ibcs… Black_David
- [Gen-art] RE: Gen-ART review of draft-martin-ibcs… Luther Martin
- [Gen-art] RE: Gen-ART review of draft-martin-ibcs… Luther Martin
- [Gen-art] RE: Gen-ART review of draft-martin-ibcs… Black_David