Subject: Re: Last Call: 'Cryptographically Generated Addresses (CGA)' to Proposed Standard

From: Pekka Savola <[email-masked]>
Date: Mon, 2 Feb 2004 09:51:00 +0200 (EET)

On Mon, 19 Jan 2004, The IESG wrote:
> - 'Cryptographically Generated Addresses (CGA) '
>    <draft-ietf-send-cga-04.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2004-02-02.

This is basically a very good document, but seems to call for a bit 
more clarity in certain places.

That is, the sections up to 5 aren't sufficiently clear, IMHO, that
using CGA itself gives you nothing (security considerations is OK
though).  Anyone possessing the public key can generate the CGA, so
that in itself provides no ownership.  Ownership can only be proven
through other protocols, or by applying the private key in a
signature.

This should require some rewording, e.g.:

   In order to verify the association between the address and the public
   key, the verifier needs to know the address itself, the public key,
   and the values of the auxiliary parameters. No additional security
   infrastructure, such as a public key infrastructure (PKI),
   certification authorities, or other trusted servers, is needed.

==> add something like, modified from the security considerations:

   Note that an attacker can create a new address from an arbitrary 
   subnet prefix and its own (or anyone else's) public key because 
   CGAs themselves are not certified -- and unless a message has been 
   specifically signed, connection to the real owner of the public key 
   can't be verified. That is, the attacker cannot impersonate 
   somebody else's address when a message is being signed using the 
   private key related to the public key used to generate the CGA.

There are other places in the first sections where this could be made 
clearer.  On their own, CGAs prove nothing.  It's only with when the 
private key is applied than some guarantees can be obtained.

Another thing which I don't think has been discussed sufficiently is
the CPU resource exhaustion attacks.  Are there ways using which the
nodes might be forced to perform heavy signature or CGA verification
steps (e.g., flood with a lot of CGA addresses, where the parameters
etc. were trivially calculated)?  Luckily enough, you can't force the
receivers to perform heavy hash2 computation (i.e., sec > 0) unless
you first break sec=0.

A few more specific comments below.

substantial
-----------

   3.  Compare the 16*Sec leftmost bits of Hash2 with zero. If they are
       all zero (or if Sec=0), continue with step (4). Otherwise,
       increment the modifier and go back to step (2).

==> the modifier is a random number.  Do you increment it by *one*
(not specified but implicit I guess) or re-randomize it?  If not
re-randomize, why not?

   6.  Concatenate from left to right the modifier, 9 zero octets, and
       the public key. Execute the SHA-1 algorithm on the concatenation.
       Take the 112 leftmost bits of the SHA-1 hash value. The result is
       Hash2.

   7.  Compare the 16*Sec leftmost bits of Hash2 with zero. If any one
       of them is non-zero, the CGA verification fails. Otherwise, the
       verification succeeds. (If Sec=0, the CGA verification never
       fails at this step.)

==> so, 7. seems to say that for the verification to succeed,
the hash2 value must be zero.  Looking again at the generation of
hash values (rules 2. and 3.) it seems that for e.g. sec=3, you'd
probably have to generate the hash function billions of times, until
the first 48 bits are all zeros.  What kind of hash computation is
that?!?!  What's the point?  Shouldn't you just generate the hash, 
and when verifying it, check that it's equal? (now it checks that it's 
zero)?

If this kind of very heavy computation is intended, it should be 
spelled out explicitly I think.

   If the verification succeeds, the verifier knows that the public key
   in the CGA Parameters is the authentic public key of the address
   owner.

==> this is an inaccurate statement.  This verification gives you
nothing except the knowledge that the CGA address has been generated
using a public key -- anyone with the public key can do it.  So, 
"authentic public key of the address owner" seems to give a hint
about the use of private address, and this is only OK after the
verifying a signature.

   Note that the values of bits 6 and 7 (the "u" and "g" bits) of the
   interface identifier are ignored during CGA verification. After the
   verification succeeds, the verifier SHOULD process all CGAs in the
   same way regardless of the Sec, modifier and collision count values.
   In particular, the verifier SHOULD NOT have any security policy that
   differentiates between addresses based on the value of Sec. That way,
   the address generator is free choose any value of Sec.

==> I find it difficult to justify this SHOULD NOT.  I feel it's
totally wrong for this document to state that you SHOULD not 
differentiate between the different strengths of an address
(e.g., if a site considers sec=0 too light, it could only treat
sec >= 1 as being "good").  This seems to be something we should
not disallow.  This would seem to be similar to saying that one SHOULD 
not differentiate security policies whether e.g. a single DES or 3DES 
was being used.

   For each valid CGA Parameters data structure, there are 4*(Sec+1)
   different CGAs that match the value. This is because decrementing the
   Sec value in the three leftmost bits of the interface identifier does
   not invalidate the address,

==> s/decrementing/changing (typically decrementing)/ -- you can up the
sec as well, even though for an attacker that's probably not lucrative --
unless maybe if CPU resource exhaustion is the goal.

Intellectual Property Statement

==> this doesn't include the note that the IETF has been notified
of some claims.  This is a must.

editorial
---------

   Discovery (SEND) protocol [I-D.ietf-send-ndopt]. The basic idea is to

==> could one use some other identifier for the drafts..?

   A cryptographically generated address is an IPv6 address for which
   the following two equations hold:

       Hash1 & Mask2  ==  interface identifier & Mask2
       Hash2 & Mask1  ==  0x0000000000000000000000000000

==> any reason why you wouldn't defined Mask2 and Mask1 the
other way, then they would be associated with the hashes of the
same number?

   address (e.g., as an RFC-3041 address [RFC3041]). An attacker does

==> s/RFC-/RFC /

  multiple pseudorandom CGAs by executing the CGA generation algorithm
   of Section 4 multiple times and by using a different random or
   pseudorandom initial value for the modifier every time. The host

==> s/by using/using/

   This document defines a new CGA Message Type name space for use as
   type tags in messages may be signed using CGA signatures.

==> s/may/that may/ ?

   The new values SHOULD be generated by the requester with a strong
   random-number generator.

==> reword to:

   The requester SHOULD generated the new values with a strong
   random-number generator.

   Michael Roe, Dave Thaler, and several other participants of the IETF
   working group.

==> s/IETF/SEND/ ?

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 3 Feb 2004 09:43:10 -0800

Hi Pekka,

Thanx for your comments. I'll forward them to Tuomas Aurea, the draft editor
for processing.

W.r.t. the timing, as usual, early review is better than later. The SEND WG
is currently in Last Call on the document draft-ietf-send-ndopts-03.txt,
expiring on Monday Feb. 9. Could you take a look at that draft and submit
comments (hopefully as detailed as those below) to the WG list prior to
expiration of Last Call, so we can incorporate them into the document before
sending it to the IESG?

            jak

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, February 01, 2004 11:51 PM
Subject: Re: Last Call: 'Cryptographically Generated Addresses (CGA)' to
Proposed Standard

> This communication is confidential and intended solely for the
addressee(s). Any unauthorized review, use, disclosure or distribution is
prohibited. If you believe this message has been sent to you in error,
please notify the sender by replying to this transmission and delete the
message without disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.