Re: [CGA-EXT] WGLC for draft-ietf-csi-hash-threat-05.txt
Jean-Michel Combes <jeanmichel.combes@gmail.com> Tue, 26 January 2010 19:20 UTC
Return-Path: <jeanmichel.combes@gmail.com>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1813A67FC for <cga-ext@core3.amsl.com>; Tue, 26 Jan 2010 11:20:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6]
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 pmsJj5CwFh+2 for <cga-ext@core3.amsl.com>; Tue, 26 Jan 2010 11:20:15 -0800 (PST)
Received: from mail-fx0-f221.google.com (mail-fx0-f221.google.com [209.85.220.221]) by core3.amsl.com (Postfix) with ESMTP id 11CD23A6954 for <cga-ext@ietf.org>; Tue, 26 Jan 2010 11:20:03 -0800 (PST)
Received: by fxm21 with SMTP id 21so901457fxm.29 for <cga-ext@ietf.org>; Tue, 26 Jan 2010 11:20:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KN9gDCvSmHB/VhZ08+2ZcTFHvywrYZl5bAWmhW/D9+Y=; b=U+QrCRsBxpjw3O8ZUP9B+a2t5Zfyt+z0IGkqXeqsOJHadH4llvrRCksJJVj5ehzg6p BxLFTy+2OZ3YvlyonanAnj7jcVemj7j1FESOIaQIfFP2QlqOcF1XtQhkk3Fo6bAC0BVD lO2vyeGgnju671q4BBVqrnHHjz5lWx+CDvJPw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=J8mvwdyqpqUDxBZ00OAgowv1FYHn7m0dOr8WmFPrXN8FRMi7pDKKcEYRPVwHIj4kzf gRtF/zmidzBiwI8KK9H/OplyjUe0SOFLbPUXPLntfZhmXQd8JKfDHpkWJSNFiM56YWZt JjjPwpbTuZmvJUt/Cc4pzB81t+31SwQPv65p8=
MIME-Version: 1.0
Received: by 10.216.162.68 with SMTP id x46mr694007wek.2.1264533604826; Tue, 26 Jan 2010 11:20:04 -0800 (PST)
In-Reply-To: <4B59E7FC.2090605@it.uc3m.es>
References: <4B59E7FC.2090605@it.uc3m.es>
Date: Tue, 26 Jan 2010 20:20:04 +0100
Message-ID: <729b68be1001261120y3a6f0f82t1c8808622ed7bc8d@mail.gmail.com>
From: Jean-Michel Combes <jeanmichel.combes@gmail.com>
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "cga-ext@ietf.org" <cga-ext@ietf.org>
Subject: Re: [CGA-EXT] WGLC for draft-ietf-csi-hash-threat-05.txt
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2010 19:20:19 -0000
Hi, here are my comments regarding this draft: SeND Hash Threat Analysis <JMC> To be compliant with RFC 3971 terminology: s/SeND/SEND <JMC> This document analysis the use of hashes in SeND, possible threats <JMC> s/SeND/SEND <JMC> and the impact of recent attacks on hash functions used by SeND. <JMC> s/SeND/SEND <JMC> Current SeND specification [rfc3971] uses the SHA-1 [sha-1] hash <JMC> s/SeND/SEND <JMC> algorithm and PKIX certificates [rfc5280] and does not provide <JMC> To cover at the same time PKI (i.e. pkix WG) certificates, actually used for SEND, and RPKI (i.e. sidr WG) certificates, used in the next version of SEND, maybe: s/PKIX certificates/X.509 certificates <JMC> support for the hash algorithm agility. The purpose of the document is to provide analysis of possible hash threats and to decide how to encode the hash agility support in SeND. <JMC> s/SeND/SEND <JMC> 1. Introduction SEND [rfc3971] uses the SHA-1 hash algorithm to generate the contents of the Key Hash field and the Digital Signature field of the RSA Signature option. It also uses a hash algorithm (SHA-1, MD5, etc.) <JMC> On one side, there is no text on use of SHA-1 to generate a CGA and, OTOH, section 2.1 explains the analysis on the CGA generation. Maybe: s/SEND [rfc3971] uses the SHA-1 hash algorithm to generate the contents of the Key Hash field and the Digital Signature field of the RSA Signature option./Secure Neighbor Discovery (SEND) [rfc3971] uses the SHA-1 hash algorithm to generate Cryptographically Generated Addresses (CGA) [rfc3972], the contents of the Key Hash field and the Digital Signature field of the RSA Signature option. <JMC> in the PKIX certificates [rfc5280] used for the router authorization <JMC> Same comment as above. To cover at the same time PKI (i.e. pkix WG) certificates, actually used for SEND, and RPKI (i.e. sidr WG) certificates, used in the next version of SEND, maybe: s/PKIX certificates/X.509 certificates <JMC> in the ADD process. Recently there have been demonstrated attacks against the collision free property of such hash functions [sha1-coll], and attacks against the PKIX X.509 certificates that use <JMC> Same comment as above. To cover at the same time PKI (i.e. pkix WG) certificates, actually used for SEND, and RPKI (i.e. sidr WG) certificates, used in the next version of SEND, maybe: s/PKIX X.509 certificates/X.509 certificates <JMC> the MD5 hash algorithm [x509-coll] This document analyzes the effects of those attacks and other possible hash attacks on the SEND protocol. The document proposes changes to make it resistant to such attacks. 2. Impact of collision attacks on SeND <JMC> s/SeND/SEND <JMC> Due to the hash attacks demonstrated on the aforesaid hash algorithms a study was performed to assess the threat of these attacks on the cryptographic hash usage in internet protocols [rfc4270]. This document analyzes the hash usage in SEND following the approach recommended by [rfc4270] and [new-hashes]. <JMC> Maybe: s/This document analyzes the hash usage in SEND following the approach recommended by [rfc4270] and [new-hashes]./This document analyzes the hash usage in SEND following the recommended approach [rfc4270][new-hashes]. <JMC> The basic cryptographic properties of a hash function are that it is both one-way and collision free. There are two attacks against the one-way property, the first-preimage attack and the second-preimage attack. In the first-preimage attack, given a knowledge of a particular value hash(m), an attacker finds an input message m' such that hash(m') yields hash(m). The second-preimage attack deals with <JMC> IMHO, for someone not familiar with cryptography, the use of "m" in hash(m) may be confusing. Maybe: s/In the first-preimage attack, given a knowledge of a particular value hash(m), an attacker finds an input message m' such that hash(m') yields hash(m)./In the first-preimage attack, given a knowledge of a particular Hash value h, an attacker finds an input message m such that yields Hash(m)=h. <JMC> the fixed messages. Given a knowledge of a fixed value m used as the input message to the hash function, an attacker finds a different value m' that yields hash(m)=hash(m'). Supposing that the hash <JMC> Just for the mathematical logic, maybe: s/Given a knowledge of a fixed value m used as the input message to the Hash function, an attacker finds a different value m' that yields hash(m)=hash(m')./Given a knowledge of a fixed value m used as the input message to the Hash function, an attacker finds a different value m' that yields Hash(m')=Hash(m). <JMC> function produces an n-bit long output, since each output is equally likely, an attack takes an order of 2^n operations to be successful. Due to the birthday attack, if the hash function is supplied with a random input, it returns one of the k equally-likely values, and the number of operations can be reduced to the number of 1.2*2^(n/2) operations. However, attacks against the one-way property are not feasible yet [rfc4270]. Up to date, all demonstrated attacks are attacks against a collision-free property, in which an attacker produces two different messages m and m' such that hash(m)=hash(m'). The rest of the document deals with the collision attacks. <JMC> As there is text in section 2.1, 2.4 about preimage attack, maybe: s/The rest of the document deals with the collision attacks./The rest of the document mainly deals with the collision attacks. <JMC> We will analyze the impact of hash attacks on SeND case by case in <JMC> s/SeND/SEND <JMC> this section. Through our analysis, we also discuss whether we should support the hash agility in SeND. <JMC> s/SeND/SEND <JMC> 2.1. Attacks against CGAs in stateless autoconfiguration Hash functions are used in the stateless autoconfiguration process that is based on CGAs. Impacts of collision attacks on current uses of CGAs are analyzed in the update of the CGA specification [rfc4982], which also enables CGAs to support the hash agility. CGAs provide the proof-of-ownership of the private key corresponding to the public key used to generate the CGA. CGAs do not deal with the <JMC> "CGAs provide the proof-of-ownership of the private key corresponding to the public key used to generate the CGA." IMHO, this sentence is unclear. What do you mean by "CGAs"? Because, AFAIK, only the RSA Signature Option (which is not a part of CGA specification, i.e. RFC 3972) provides the proof-of-ownership of the generated CGA: the public key used to generate the CGA is really owned by the sender because this last one has correctly signed the ND message and so he owns the private key associated to the public key. Or did I miss something? <JMC> non-repudiation feature, while collision attacks are mainly about affecting the non-repudiation feature, i.e. in the collision attack against the CGA both of the CGA Parameters sets are choosen by an attacker, which is not useful in the real-world scenarios. <JMC> "which is not useful in the real-world scenarios" Out of curiosity, may you explain to me why you have such a conclusion? <JMC> Therefore, as [rfc4982] points out CGA based protocols, including SeND, are not affected by the recent collision attacks. Regarding <JMC> s/SeND/SEND <JMC> the pre-image attacks, if pre-image attacks were feasible, an attacker would manage to find the new CGA Parameters based on the associated, victim's CGA, and produce the Key Hash field and the Digital Signature field afterwards using the new public key. Since the strength of all hashes in SEND depends on the strength of the CGA, the pre-image attack is potentially dangerous, but it is not yet feasible. <JMC> s/pre-image/preimage <JMC> 2.2. Attacks against PKIX certificates in ADD process <JMC> s/PKIX certificates/X.509 certificates <JMC> The second use of hash functions is for the router authorization in the ADD process. Router sends to a host a certification path, which is a path between a router and the hosts's trust anchor, consisting of PKIX certificates. Researchers demonstrated attacks against PKIX <JMC> s/hosts's/host's s/PKIX certificates/X.509 certificates <JMC> certificates with MD5 signature, in 2005 [new-hashes] and in 2007 [x509-coll]. In 2005 were constructed the original and the false certificate that had the same identity data and the same digital signature, but different public keys [new-hashes]. The problem for the attacker is that two certificates with the same identity are not actually useful in real-world scenarios, because the Certification Authority is not allowed to provide such two certificates. In <JMC> "because the Certification Authority is not allowed to provide such two certificates." Warning: AFAIK, there are methods, today, to get and to use such a certificate from a CA (e.g. use of the "wildcard" or "null prefix" method in the CN). That's already be done for SSL. <JMC> addition, attacks against the human-readable fields demand much more effort than the attacks against non human-readable fields, such as a public key field. In case of the identity field, an attacker is faced with the problem of the prediction and the generation of the false but meaningful identity data, which at the end might be revealed by the Certification Authority. Thus, in practice, collision attacks do not affect non human-readable parts of the certificate. In 2007 were demonstrated certificates which differ in the identity data and in the public key, but still result in the same signature value. In such attack, even if an attacker produced such two certificates in order to claim that he was someone else, he still needs to predict the content of all fields appearing before the public key, e.g. the serial number and validity periods. Although a relying party cannot verify the content of these fields (each certificate by itself is unsuspicious), the Certification Authority keeps track of those fields and it can reveal the false certificate during the fraud analysis. Regarding certificates in SeND, <JMC> s/SeND/SEND <JMC> potentially dangerous are attacks against the X.509 certificate extensions. For example, an attack against the IP address extension would enable the router to advertize the changed IP prefix range, although, not broader than the prefix range of the parent certificate in the ADD chain. The public-private key pair associated to the Router Authorization Certificate in the ADD process is used both for the CGA generation and for the message signing. Since in the future CGAs might be used <JMC> "both for the CGA generation and for the message signing." I assume you mean when the router uses also CGA Option. Correct? <JMC> only with certificates, attacks against certificates are even more dangerous. Generally, the most dangerous are attacks against middle- certificates in the certification path, where for the cost of the one false certificate, an attacker launches an attack on multiple routers. Regarding the attacks against certificates in SEND, the only attack that SEND is not suspectable to, is an attack against the Trust Anchor's certificate because it is not exchanged in SeND <JMC> s/SeND/SEND <JMC> messages, i.e. it is not the part of the certification path in the ADD process. 2.4. Attacks against the Key Hash field in the RSA Signature option The Key Hash field is a SHA-1 hash of the public key from the CGA Parameters structure in the CGA option. The pre-image attack against <JMC> s/pre-image/preimage <JMC> the Key Hash field is potentially dangerous, as in the case of all other hashes in SEND, because the Key Hash field contains a non human-readable data. However the Key Hash field is not suspectable to the collision attack, since in the collision attack an attacker itself chooses both keys, k and k', where hash(k) = hash(k'). The reason for the former is that the associated public key is already authorized through the use of CGAs, and possibly the certification path in the ADD process. 3. Support for the hash agility in SeND <JMC> s/SeND/SEND <JMC> While all of analyzed hash functions in SeND are theoretically <JMC> s/SeND/SEND <JMC> affected by hash attacks, these attacks indicate the possibility of future real-world attacks. In order to increase the future security of SeND, the following possible approaches can be used. <JMC> s/SeND/SEND <JMC> o The most effective and secure would be to bind the hash function option with something that can not be changed at all, like [rfc4982] does for CGA - encoding the hash function information into addresses. But, there is no possibilty to do that in SeND. <JMC> s/possibilty/possibility s/SeND/SEND <JMC> We could decide to use by default the same hash function in SeND <JMC> s/SeND/SEND <JMC> as in CGA. The security of all hashes in SeND depends on CGA, ie. <JMC> s/SeND/SEND <JMC> if an attacker could break CGA, all other hashes are automatically broken. From the security point of view, at the moment, this solution is more reasonable then defining different hash algorithm for each hash. Additionally, if using the hash algorithm from the CGA, no bidding down attacks are possible. On the other hand, this solution introduces the limition for SEND to be used <JMC> s/limition/limitation <JMC> exclusively with CGAs. o Another solution is to incorporate the Hash algorithm option into the SeND message. However, if the algorithm is defined in the <JMC> s/SeND/SEND <JMC> Hash algorithm option in the SeND message, it is vulnerable to the bidding down attack. <JMC> s/SeND/SEND <JMC> 4. Security Considerations This document analyzes the impact of hash attacks in SeND and offeres <JMC> s/SeND/SEND s/offeres/offers <JMC> a higher security level for SeND by providing solution for the hash <JMC> s/SeND/SEND <JMC> agility support. The negotiation approach for the hash agility in SeND based on the <JMC> s/SeND/SEND <JMC> Supported Signature Algorithms option is vulnerable to bidding-down attacks, which is usual in the case of any negotiation approach. This issue can be mitigated with the appropriate local policies. Hope that helps. Best regards. JMC. 2010/1/22 marcelo bagnulo braun <marcelo@it.uc3m.es>: > Hi, > > This is WGLC for draft-ietf-csi-hash-threat-05.txt. > Please read the document and provide comments. The WGLC will close on the > 8th of february. > > the draft can be found at: > > http://tools.ietf.org/id/draft-ietf-csi-hash-threat-05.txt > > Regards, marcelo > > _______________________________________________ > CGA-EXT mailing list > CGA-EXT@ietf.org > https://www.ietf.org/mailman/listinfo/cga-ext >
- [CGA-EXT] WGLC for draft-ietf-csi-hash-threat-05.… marcelo bagnulo braun
- Re: [CGA-EXT] WGLC for draft-ietf-csi-hash-threat… Jean-Michel Combes
- [CGA-EXT] [Fwd: Re: WGLC for draft-ietf-csi-hash-… marcelo bagnulo braun
- Re: [CGA-EXT] [Fwd: Re: WGLC for draft-ietf-csi-h… Ana Kukec
- Re: [CGA-EXT] WGLC for draft-ietf-csi-hash-threat… Sheng Jiang
- Re: [CGA-EXT] WGLC for draft-ietf-csi-hash-threat… Ana Kukec