Re: [CGA-EXT] WGLC for draft-ietf-csi-hash-threat-05.txt

[Sheng Jiang <[e-mail]>]

Jean-Michel,

Thanks so much for your comments. We will integrate your comments in a new
version that will be issued after the WGLC is completed.

Regards,

Sheng

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Jean-Michel Combes
> Sent: Wednesday, January 27, 2010 3:20 AM
> To: marcelo bagnulo braun
> Cc: [e-mail]
> Subject: Re: [CGA-EXT] WGLC for draft-ietf-csi-hash-threat-05.txt
> 
> 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 <[e-mail]>:
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/cga-ext
> >
> _______________________________________________
> CGA-EXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cga-ext