Subject: Detailed text changes to the CGA draft to resolve CGA issue #12

From: "Tuomas Aura" <[email-masked]>
Date: Wed, 24 Mar 2004 18:52:12 -0800

This is a detailed proposal for resolving CGA issue #12:
upgrade path for crypto algorithms. The changes below are to
the CGA draft. Corresponding changes needs to be made to the 
NDOPT draft. Please see my previous email for the motivation.

The key changes are to Section 3 where the CGA Parameters 
data structure is now specified with the help of a diagram,
and may have optional extension fields at its end.
The entire CGA Parameters data structure should be sent as
an opaque block of bytes in the CGA Option (see Section 5.1 
of the NDOPT draft). 

The proposed changes to the CGA draft follow.
(CHANGE 1) Rewrite Section 3. CGA Parameters and Hash Values:

 3. CGA Parameters and Hash Values

   Each CGA is associated with a CGA Parameters data structure, which
   has the following format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                      Modifier (16 octets)                     +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                    Subnet Prefix (8 octets)                   +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Collision Count|                                               |
    +-+-+-+-+-+-+-+-+                                               |
    |                                                               |
    ~                  Public Key (variable length)                 ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~           Extension Fields (optional, variable length)        ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Modifier

      This field contains an 128-bit unsigned integer , which can be any
      value. The modifier is used during CGA generation to implement the
      hash extension and to enhance privacy by adding randomness to the
      address.

   Subnet Prefix

      This field contains the 64-bit subnet prefix of the CGA.

   Collision Count

      This is an 8-bit unsigned integer, which MUST be 0, 1 or 2. The
      collision count is incremented during CGA generation to recover
      from an address collision detected by duplicate address detection.

   Public Key

      This is a variable length field containing the public key of the
      address owner. The public key MUST be formatted as a DER-encoded
      [ITU.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo
      defined in the Internet X.509 certificate profile [RFC3280]. SEND
      SHOULD use an RSA public/private key pair. When RSA is used, the
      algorithm identifier MUST be rsaEncryption, which is
      1.2.840.113549.1.1.1, and the RSA public key MUST be formatted
      using RSAPublicKey type as specified in Section 2.3.1 of RFC 3279
      [RFC3279]. The RSA key length SHOULD be at least 384 bits. Other
      public key types or format SHOULD NOT be used for SEND to avoid
      incompatibilities [I-D.ietf-send-ndopt] between implementations.
      The length of the public key is determined by the ASN.1 encoding.

   Extension Fields

      This is an optional variable-length field, which is not used in
      the current specification. Future versions of this specification
      may use this field for additional data that needs to be included
      in CGA Parameters data structure. IETF standards action is
      required to specify the use of the extension fields.
      Implementations MUST ignore the value of any unrecognized
      extension fields.

   The two hash values MUST be computed as follows. The SHA-1 hash
   algorithm [FIPS.180-1.1995] is applied to the CGA Parameters. When
   computing Hash1, the input to the SHA-1 algorithm is the CGA
   Parameters data structure. The 64-bit Hash1 is obtained by taking the
   leftmost 64 bits of the 160-bit SHA-1 hash value. When computing
   Hash2, the input is the same CGA Parameters data structure except
   that the subnet prefix and collision count are set to zero. The
   112-bit Hash2 is obtained by taking the leftmost 112 bits of the
   160-bit SHA-1 hash value. Note that the hash values are computed over
   the entire CGA Parameters data structure, including any unrecognized
   extension fields.

(CHANGE 2) Add to the end of Section 4. CGA Generation:

   Future versions of this specification may specify additional inputs
   to the CGA generation algorithm, which are concatenated as extension
   fields to the end of the CGA Parameters data structure. This document
   does not specify how such data fields are handled during CGA
   generation.

(CHANGE 3) Change 2 sentences in Section 5. CGA Verification:  

   The CGA Parameters consist of the concatenated
   modifier, subnet prefix, collision count, public key, and optional
   extension fields.

   Concatenate from left to right the modifier, 9 zero octets, and
   the public key, and any extension fields that follow the public
   key in the CGA Parameters data structure.

(CHANGE 4) Add to the end of Section 5. CGA Verification:

   Implementations of CGA verification MUST ignore the value of any
   unrecognized extension fields that follow the public key in the CGA
   Parameters data structure. However, implementations MUST include any
   such unrecognized data in the hash input when computing Hash1 in step
   (3) and Hash2 in step (6) of the CGA verification algorithm. This is
   important to ensure upward compatibility with future extensions.

Tuomas

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