Hi, 2008/7/1 Ana Kukec <[EMAIL PROTECTED]>: > The new version of draft-kukec-csi-hash-threat is submitted. Comments are > welcome! >
Please see my inline comments. > SeND Hash Threat Analysis > draft-kukec-csi-hash-threat-02 > [snip] > > 1. Introduction > > SEND [rfc3971] uses the SHA-1 hash algorithm to generate the contents > of the Key Hash and the Digital Signature fields of the RSA > signature. It also uses a hash algorithm (SHA-1,MD5 etc.) in the > PKIX certificates [rfc3280] used for router authorization. Recently > there have been demonstrated attacks against the collision free > property of such hash functions [sha1-coll]. There have also been > attacks on the PKIX X.509 certificates that use the MD5 hash > algorithm [x509-coll] that allow an attacker to generate two > different certificates with different distinguished names and > different public keys that contain identical signatures. This > document analyzes the effects of such attacks on the SEND protocol > and proposes changes to make it resistant to such attacks. > > IMHO, the reference/text to the attacks on hash functions used for the certificate generation is out of scope because this issue is/should be studied in the PKIX WG and is not strictly linked to SEND: there is the same issue when certs are used with other security services (e.g. IPsec). [snip] > > 3.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 CGA specification [rfc4982], > which also enables CGAs to support hash agility. CGAs provide proof- > of-ownership of the private key corresponding to the public key used > to generate CGA, and they don't deal with the non-repudiation > feature, while collision attacks are mainly about affecting non- > repudiation feature. While SeND is CGA based protocol, we are sure > that the node that signs the message is the same as the node that > creates the message and associated hash. So, as [rfc4982] points out > CGA based protocols, including SeND, are not affected by the recent > collision attacks. > IMHO, it would be better to speak about "CGA generation" than "CGAs in stateless autoconfiguration" because: - The hash function is used during the CGA generation (i.e. RFC 3972) - CGA may be used with stateful mechanisms (e.g. IKEv2) > 3.2. Attacks against PKIX certificates in ADD process Please see my previous comment about my feeling that attacks against hash functions in certs are out of scope. [snip] > 3.3. Attacks against Digital Signature in RSA Signature option > > Digital signature in RSA Signature option is produced as the SHA-1 > hash of IPv6 addresses, ICMPv6 header, ND message and other fields > like Message Type Tag and ND options [rfc3971], and is signed with > the sender's private key, which corresponds to the public key from > the CGA parameters structure and is authorized usually through CGAs. > The possible attack on such explicit digital signature is typical > non-repudiation attack. Attacker could generate a false message with > the same hash and sign that false hashed message with authorized > private key. However, the problem for the attacker is that they are > very hard to predict the useful input data. It minimizes the > possibility for a real-world collision attack and the fact that in > order to perform a succesful real-world attack he can not change a s/succesful/successful [snip] > 3.4. Attacks against Key Hash in RSA Signature option > > Key Hash field in the RSA Signature option is a SHA-1 hash of the > public key from the CGA parameters structure in the CGA option of > SeND message. Key Hash field is a typical example of data > fingerprinting, which is potentially dangerous because input field is > a non human-readable data. But the problem for the attacker is that > a public key, which is input data is authorized through CGAs, and > sometimes additionally through a certification path if peer has > configured trust anchor. For the succesful attack, attacker has to s/succesful/successful [snip] > > 4. Support for the hash agility in SeND > [snip] > 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. s/possibilty/possibility [snip] > 4.1. Hash algorithm option > > In order to provide hash algorithm agility, each SeND implemenation s/implemenation/implementation [snip] > Hash Algorithm for Key Hash field (HA-KH) > > Hash algorithm used for producing the Key Hash field in the RSA > Signature option. SEND [rfc3971] uses SHA-a. In order to provide s/SHA-a/SHA-1 [snip] > > Reserved > > Field reserved for future uses. The value MUST be initialized to > zero by the sender, and MUST be ignored by the recepient. s/recepient/recipient [snip] > > 5. Security Considerations > > This document analyzes the impact of hash attacks in SeND and offeres s/offeres/offers [snip] Best regards. JMC. _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
