Re: [CGA-EXT] new version of "Send Hash Threat Analysis"

["Jean-Michel Combes" <jeanmichel.combes at gmail.com>]

Hi,

2008/7/1 Ana Kukec <anchie at fer.hr>:
> 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
CGA-EXT at ietf.org
https://www.ietf.org/mailman/listinfo/cga-ext