Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211
denis.pinkas@bull.net Thu, 31 May 2012 16:22 UTC
Return-Path: <denis.pinkas@bull.net>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0025D21F86A5 for <pkix@ietfa.amsl.com>; Thu, 31 May 2012 09:22:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level:
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiwZS6MsMv+K for <pkix@ietfa.amsl.com>; Thu, 31 May 2012 09:22:55 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDE721F869C for <pkix@ietf.org>; Thu, 31 May 2012 09:22:55 -0700 (PDT)
Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 5F25F12000E; Thu, 31 May 2012 18:22:54 +0200 (CEST)
In-Reply-To: <4FC6AEDA.4010709@cs.tcd.ie>
References: <4FC6AEDA.4010709@cs.tcd.ie>
To: rra@stanford.edu, hotz@jpl.nasa.gov, Jim Schaad <ietf@augustcellars.com>
MIME-Version: 1.0
X-KeepSent: 2C174BF8:9661F84B-C1257A0F:0035B9F3; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010
From: denis.pinkas@bull.net
Message-ID: <OF2C174BF8.9661F84B-ONC1257A0F.0035B9F3-C1257A0F.0059FC5B@bull.net>
Date: Thu, 31 May 2012 18:22:53 +0200
X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 31/05/2012 18:22:54, Serialize complete at 31/05/2012 18:22:54
Content-Type: multipart/alternative; boundary="=_alternative 0059D8ADC1257A0F_="
Cc: pkix <pkix@ietf.org>
Subject: Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 May 2012 16:22:57 -0000
Henry, Russ and Jim, I skimmed through the document and read the following two sentences: The public key in the request is sent in the clear, and without any guarantees that the requestor actually possesses the corresponding private key. [RFC4211], Appendix C contains a more detailed discussion of why proof-of- possession is important. I have concerns with both sentences. [RFC4211] is incorrect and this has security implications on the proposed protocol. A part of Annex C is copied below, with text which should be added in bold characters. POP is important because it provides an appropriate level of assurance of the correct operation of the PKI as a whole. At its lowest level, POP counters the "self-inflicted denial of service"; that is, an entity voluntarily gets a certificate that cannot be used to sign or encrypt/decrypt information. However, as the following two examples demonstrate, POP also counters less direct, but more severe, threats: POP for signing keys: it is important to provide POP for keys used to sign material, in order to provide non-repudiation of transactions. For example, suppose Alice legitimately has private key X and its corresponding public key Y. Alice has a certificate from Charlie, a CA, containing Y. Alice uses X to sign a transaction T. Without POP, Mal could also get a certificate from Charlie containing the same public key, Y. Now, there are two possible threats: Mal could claim to have been the real signer of T; or Alice can falsely deny signing T, claiming that it was instead Mal. One could say, since no one can reliably prove that Mal did or did not ever possess X, neither of these claims can be refuted, and thus the service provided by and the confidence in the PKI has been defeated. However, since Alice legitimately has private key X and its corresponding public key Y, she will ask her certificate first. When the Alice’s certificate will be distributed, Mal takes a copy of the public key present in her certificate and requests a certificate for himself. By comparing the logs in the CA databases, it is possible to know which one asked the certificate first and then tell that Alice is the legitimate holder. However, this means that the public key must be confidentiality protected during its transit to the RA, in order to prevent Mal to copy it. (Of course, if Mal really did possess X, Alice's private key, then no POP mechanism in the world will help, but that is a different problem.) Note that one level of protection can be gained by having Alice (as the true signer of the transaction) include in the signed information, her certificate or an identifier of her certificate (e.g., a hash of her certificate). Alice could maliciously include Mal’s certificate rather than her certificate in the transaction. In case of a dispute, the logs present in the CA databases will be used and the only legitimate certificate will be the one which was issued earlier. It is thus possible to demonstrate that Alice was malicious. The following text from Annex C should be deleted. This might make it more difficult for Mal to claim authorship; he would have to assert that he incorrectly included Alice's certificate, rather than his own. However, it would not stop Alice from falsely repudiating her actions. Since the certificate itself is a public item, Mal indeed could have inserted Alice's certificate or identifier into the signed transaction, and thus its presence does not indicate that Alice was the one who participated in the now-repudiated transaction. The only reliable way to stop this attack is to require that Mal prove he possesses X before his certificate is issued. The implication is that the message defined in draft-hotz-kx509 which carries the public key MUST BE somehow confidentiality and integrity protected. Denis PS. I am not on the Kerberos list, so please respond directly or/and to the pkix list. De : Stephen Farrell <stephen.farrell@cs.tcd.ie> A : pkix <pkix@ietf.org>, "krb-wg mailing list (ietf-krb-wg@lists.anl.gov)" <ietf-krb-wg@lists.anl.gov> Date : 31/05/2012 01:36 Objet : [pkix] RFC 5742 review of draft-hotz-kx509 Envoyé par : pkix-bounces@ietf.org Hi, The independent submissions editor (ISE) has asked the IESG to do an RFC 5742 review of this [1] document. That review is to check that the publication of this independent stream submission would not conflict with IETF work. In this case, the work is clearly related to the pkix and kerberos working groups, hence this mail. Note: this mail is not a request for a technical review of the content, but rather asking if publication would somehow be damaging to the work of these wgs. (If you do have technical comments, send them to the author or ISE). If you're not sure about any of that, then read RFC 5742. [2] I'll take silence as meaning that nobody thinks that there's a conflict. If someone thinks there is a conflict let me, the list, or the wg chairs know. In due course, I'll be doing my own evaluation as well of course, as will other IESG members. Thanks, Stephen. [1] http://tools.ietf.org/html/draft-hotz-kx509-04 [2] http://tools.ietf.org/html/rfc5742 _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix
- [pkix] RFC 5742 review of draft-hotz-kx509 Stephen Farrell
- Re: [pkix] RFC 5742 review of draft-hotz-kx509 an… denis.pinkas
- Re: [pkix] RFC 5742 review of draft-hotz-kx509 an… Russ Allbery
- Re: [pkix] RFC 5742 review of draft-hotz-kx509 an… denis.pinkas
- Re: [pkix] RFC 5742 review of draft-hotz-kx509 an… Henry B. Hotz
- Re: [pkix] [Ietf-krb-wg] RFC 5742 review of draft… Sam Hartman
- Re: [pkix] RFC 5742 review of draft-hotz-kx509 an… Stephen Kent
- [pkix] Fwd: RFC 5742 review of draft-hotz-kx509 Stephen Farrell