Subject: Re: Type tags and pseudo-messages

From: <[email-masked]>
Date: Thu, 7 Aug 2003 16:54:08 +0300

> Yes, you can do that. Except that I would prefer the value to be 
> really generated in random. (Two "random" values invented by
> C001 D00Ds are more likely to collide than two random numbers.))

Ok!

>>> Current document includes the whole packet under the digital
>>> signature. This includes therefore also the ICMP Type. Would
>>> that be sufficient with a single tag value for SEND?
> 
> 
> If, indeed, the whole packet is signed, then the SEND needs only 
> one tag value because the ICMP Type can be used to differentiate
> between SEND messages. Otherwise, it is a matter of taste where
> to put the part of the type tag that differentiates between the 
> different SEND messages. The way the new CGA spec is written, it 
> allows for consecutive type tag values to be used for SEND messages, 
> starting from a random one. But I'm just as happy to use only one 
> tag for SEND.

Ok, lets do that then.

> BTW, I believe that we should not be signing the entire packet. 
> I'd rather define pseudo-message that contains only the relevant 
> fields and sign that. Some arguments for signing pseudo-messages:
> 
> (1) We need to define some kind of pseudo-messages anyway because 
> some IP header fields and the signature itself need to be excluded 
> from the signed part.

Not the header fields, since this is local traffic. Francis pointed
this out earlier. But yes for the signature itself.

> (2) If the entire packet is singed, it becomes necessary to guess
> the size of the signature before signing. This may be relatively easy
> but ugly anyway.

Yes.

> (3) Protocol extensions, such as proxy ND and RD, may need to 
> include the signed SEND message in another message or to have 
> multiple signatures on a single SEND message. 

Perhaps. But I think its more likely that we'd have a Certificate option somewhere to carry the authorization of the original address owner to the new node.

Allright. How about this text:

   Digital Signature

      This variable length field contains the signature made using the
      sender's private key, over the the following sequence of octets:

      1.  The 128-bit CGA Message Type [27] value for SEND, 0xXXXX XXXX
          XXXX XXXX XXXX XXXX XXXX XXXX (To be generated randomly).

      2.  The 128-bit Source Address field from the IP header.

      3.  The 128-bit Destination Address field from the IP header.

      4.  The 32-bit ICMP header, i.e., the Type, Code, and Checksum
          fields.

      5.  The Neighbor Discovery message header, i.e., the Reserved
          field in the Router Solicitation message, the Cur Hop Limit,
          M, O, Reserved, Router Lifetime, Reachable Time, and Retrans
          Timer fields in the Router Advertisement message, Reserved and
          Target Address fields in the Neighbor Solicitation message, R,
          S, O, Reserved, and Target Address fields in the Neighbor
          Advertisement message, and Reserved, Target Address, and
          Destination Address fields in the Redirect message.

      6.  All options preceding the Signature option.

--------------------------------------------------------------------
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
--------------------------------------------------------------------

---

From: "Tuomas Aura" <[email-masked]>
Date: Thu, 7 Aug 2003 07:18:38 -0700

Sounds good to me. Is far as I can see, this is unambiguous 
and easy to compute. 
Tuomas