doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc3972.txt b/doc/rfc/rfc3972.txt
new file mode 100644
index 0000000..9c7a7ab
--- /dev/null
+++ b/doc/rfc/rfc3972.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                            T. Aura
+Request for Comments: 3972                            Microsoft Research
+Category: Standards Track                                     March 2005
+
+
+              Cryptographically Generated Addresses (CGA)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document describes a method for binding a public signature key
+   to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol.
+   Cryptographically Generated Addresses (CGA) are IPv6 addresses for
+   which the interface identifier is generated by computing a
+   cryptographic one-way hash function from a public key and auxiliary
+   parameters.  The binding between the public key and the address can
+   be verified by re-computing the hash value and by comparing the hash
+   with the interface identifier.  Messages sent from an IPv6 address
+   can be protected by attaching the public key and auxiliary parameters
+   and by signing the message with the corresponding private key.  The
+   protection works without a certification authority or any security
+   infrastructure.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aura                        Standards Track                     [Page 1]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  CGA Format . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  CGA Parameters and Hash Values . . . . . . . . . . . . . . . .  5
+   4.  CGA Generation . . . . . . . . . . . . . . . . . . . . . . . .  6
+   5.  CGA Verification . . . . . . . . . . . . . . . . . . . . . . .  9
+   6.  CGA Signatures . . . . . . . . . . . . . . . . . . . . . . . . 10
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+       7.1.  Security Goals and Limitations . . . . . . . . . . . . . 12
+       7.2.  Hash Extension . . . . . . . . . . . . . . . . . . . . . 13
+       7.3.  Privacy Considerations . . . . . . . . . . . . . . . . . 15
+       7.4.  Related Protocols  . . . . . . . . . . . . . . . . . . . 15
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+       9.1.  Normative References . . . . . . . . . . . . . . . . . . 17
+       9.2.  Informative References . . . . . . . . . . . . . . . . . 18
+   Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+       A.  Example of CGA Generation. . . . . . . . . . . . . . . . . 20
+       B.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . 21
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
+   Full Copyright Statements. . . . . . . . . . . . . . . . . . . . . 22
+
+1.  Introduction
+
+   This document specifies a method for securely associating a
+   cryptographic public key with an IPv6 address in the Secure Neighbor
+   Discovery (SEND) protocol [RFC3971].  The basic idea is to generate
+   the interface identifier (i.e., the rightmost 64 bits) of the IPv6
+   address by computing a cryptographic hash of the public key.  The
+   resulting IPv6 address is called a cryptographically generated
+   address (CGA).  The corresponding private key can then be used to
+   sign messages sent from the address.  An introduction to CGAs and
+   their application to SEND can be found in [Aura03] and [AAKMNR02].
+
+   This document specifies:
+
+   o  how to generate a CGA from the cryptographic hash of a public key
+      and auxiliary parameters,
+
+   o  how to verify the association between the public key and the CGA,
+      and
+
+   o  how to sign a message sent from the CGA, and how to verify the
+      signature.
+
+
+
+
+
+
+Aura                        Standards Track                     [Page 2]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+   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.  The verifier can then go on to
+   verify messages signed by the owner of the public key (i.e., the
+   address owner).  No additional security infrastructure, such as a
+   public key infrastructure (PKI), certification authorities, or other
+   trusted servers, is needed.
+
+   Note that because CGAs themselves are not certified, an attacker can
+   create a new CGA from any subnet prefix and its own (or anyone
+   else's) public key.  However, the attacker cannot take a CGA created
+   by someone else and send signed messages that appear to come from the
+   owner of that address.
+
+   The address format and the CGA parameter format are defined in
+   Sections 2 and 3.  Detailed algorithms for generating addresses and
+   for verifying them are given in Sections 4 and 5, respectively.
+   Section 6 defines the procedures for generating and verifying CGA
+   signatures.  The security considerations in Section 7 include
+   limitations of CGA-based security, the reasoning behind the hash
+   extension technique that enables effective hash lengths above the
+   64-bit limit of the interface identifier, the implications of CGAs on
+   privacy, and protection against related-protocol attacks.
+
+   In this document, the key words MUST, MUST NOT, REQUIRED, SHALL,
+   SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to
+   be interpreted as described in [RFC2119].
+
+2.  CGA Format
+
+   When talking about addresses, this document refers to IPv6 addresses
+   in which the leftmost 64 bits of a 128-bit address form the subnet
+   prefix and the rightmost 64 bits of the address form the interface
+   identifier [RFC3513].  We number the bits of the interface identifier
+   starting from bit zero on the left.
+
+   A cryptographically generated address (CGA) has a security parameter
+   (Sec) that determines its strength against brute-force attacks.  The
+   security parameter is a three-bit unsigned integer, and it is encoded
+   in the three leftmost bits (i.e., bits 0 - 2) of the interface
+   identifier.  This can be written as follows:
+
+      Sec = (interface identifier & 0xe000000000000000) >> 61
+
+
+
+
+
+
+
+
+Aura                        Standards Track                     [Page 3]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+   The CGA is associated with a set of parameters that consist of a
+   public key and auxiliary parameters.  Two hash values Hash1 (64 bits)
+   and Hash2 (112 bits) are computed from the parameters.  The formats
+   of the public key and auxiliary parameters, and the way to compute
+   the hash values, are defined in Section 3.
+
+   A cryptographically generated address is defined as an IPv6 address
+   that satisfies the following two conditions:
+
+   o  The first hash value, Hash1, equals the interface identifier of
+      the address.  Bits 0, 1, 2, 6, and 7 (i.e., the bits that encode
+      the security parameter Sec and the "u" and "g" bits from the
+      standard IPv6 address architecture format of interface identifiers
+      [RFC3513]) are ignored in the comparison.
+
+   o  The 16*Sec leftmost bits of the second hash value, Hash2, are
+      zero.
+
+   The above definition can be stated in terms of the following two bit
+   masks:
+
+      Mask1 (64 bits)  = 0x1cffffffffffffff
+
+      Mask2 (112 bits) = 0x0000000000000000000000000000  if Sec=0,
+                         0xffff000000000000000000000000  if Sec=1,
+                         0xffffffff00000000000000000000  if Sec=2,
+                         0xffffffffffff0000000000000000  if Sec=3,
+                         0xffffffffffffffff000000000000  if Sec=4,
+                         0xffffffffffffffffffff00000000  if Sec=5,
+                         0xffffffffffffffffffffffff0000  if Sec=6, and
+                         0xffffffffffffffffffffffffffff  if Sec=7
+
+   A cryptographically generated address is an IPv6 address for which
+   the following two equations hold:
+
+      Hash1 & Mask1  ==  interface identifier & Mask1
+      Hash2 & Mask2  ==  0x0000000000000000000000000000
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aura                        Standards Track                     [Page 4]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+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 a 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 eight-bit unsigned integer that 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.
+
+
+
+Aura                        Standards Track                     [Page 5]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+   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 by
+      using the 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 are undesirable in SEND, as they may result
+      in incompatibilities between implementations.  The length of this
+      field is determined by the ASN.1 encoding.
+
+   Extension Fields
+
+      This is an optional variable-length field that is not used in the
+      current specification.  Future versions of this specification may
+      use this field for additional data items that need to be included
+      in the 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
+   Hash1 is computed, 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 Hash2 is
+   computed, 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.
+
+4.  CGA Generation
+
+   The process of generating a new CGA takes three input values: a
+   64-bit subnet prefix, the public key of the address owner as a
+   DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo, and the
+   security parameter Sec, which is an unsigned three-bit integer.  The
+   cost of generating a new CGA depends exponentially on the security
+   parameter Sec, which can have values from 0 to 7.
+
+
+
+
+
+
+Aura                        Standards Track                     [Page 6]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+   A CGA and associated parameters SHOULD be generated as follows:
+
+   1. Set the modifier to a random or pseudo-random 128-bit value.
+
+   2. Concatenate from left to right the modifier, 9 zero octets, the
+      encoded public key, and any optional extension fields.  Execute
+      the SHA-1 algorithm on the concatenation.  Take the 112 leftmost
+      bits of the SHA-1 hash value.  The result is Hash2.
+
+   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 by one and go back to step 2.
+
+   4. Set the 8-bit collision count to zero.
+
+   5. Concatenate from left to right the final modifier value, the
+      subnet prefix, the collision count, the encoded public key, and
+      any optional extension fields.  Execute the SHA-1 algorithm on the
+      concatenation.  Take the 64 leftmost bits of the SHA-1 hash value.
+      The result is Hash1.
+
+   6. Form an interface identifier from Hash1 by writing the value of
+      Sec into the three leftmost bits and by setting bits 6 and 7
+      (i.e., the "u" and "g" bits) to zero.
+
+   7. Concatenate the 64-bit subnet prefix and the 64-bit interface
+      identifier to form a 128-bit IPv6 address with the subnet prefix
+      to the left and interface identifier to the right, as in a
+      standard IPv6 address [RFC3513].
+
+   8. Perform duplicate address detection if required, as per [RFC3971].
+      If an address collision is detected, increment the collision count
+      by one and go back to step 5.  However, after three collisions,
+      stop and report the error.
+
+   9. Form the CGA Parameters data structure by concatenating from left
+      to right the final modifier value, the subnet prefix, the final
+      collision count value, the encoded public key, and any optional
+      extension fields.
+
+   The output of the address generation algorithm is a new CGA and a CGA
+   Parameters data structure.
+
+   The initial value of the modifier in step 1 SHOULD be chosen randomly
+   to make addresses generated from the same public key unlinkable,
+   which enhances privacy (see Section 7.3).  The quality of the random
+   number generator does not affect the strength of the binding between
+
+
+
+
+Aura                        Standards Track                     [Page 7]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+   the address and the public key.  Implementations that have no strong
+   random numbers available MAY use a non-cryptographic pseudo-random
+   number generator initialized with the current time of day.
+
+   For Sec=0, the above algorithm is deterministic and relatively fast.
+   Nodes that implement CGA generation MAY always use the security
+   parameter value Sec=0.  If Sec=0, steps 2 - 3 of the generation
+   algorithm can be skipped.
+
+   For Sec values greater than zero, the above algorithm is not
+   guaranteed to terminate after a certain number of iterations.  The
+   brute-force search in steps 2 - 3 takes O(2^(16*Sec)) iterations to
+   complete.  The algorithm has been intentionally designed so that the
+   generation of CGAs with high Sec values is infeasible with current
+   technology.
+
+   Implementations MAY use optimized or otherwise modified versions of
+   the above algorithm for CGA generation.  However, the output of any
+   modified versions MUST fulfill the following two requirements.
+   First, the resulting CGA and CGA Parameters data structure MUST be
+   formatted as specified in Sections 2 - 3.  Second, the CGA
+   verification procedure defined in Section 5 MUST succeed when invoked
+   on the output of the CGA generation algorithm.  Note that some
+   optimizations involve trade-offs between privacy and the cost of
+   address generation.
+
+   One optimization is particularly important.  If the subnet prefix of
+   the address changes but the address owner's public key does not, the
+   old modifier value MAY be reused.  If it is reused, the algorithm
+   SHOULD be started from step 4.  This optimization avoids repeating
+   the expensive search for an acceptable modifier value but may, in
+   some situations, make it easier for an observer to link two addresses
+   to each other.
+
+   Note that this document does not specify whether duplicate address
+   detection should be performed and how the detection is done.  Step 8
+   only defines what to do if some form of duplicate address detection
+   is performed and an address collision is detected.
+
+   Future versions of this specification may specify additional inputs
+   to the CGA generation algorithm that are concatenated as extension
+   fields to the end of the CGA Parameters data structure.  No such
+   extension fields are defined in this document.
+
+
+
+
+
+
+
+
+Aura                        Standards Track                     [Page 8]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+5.  CGA Verification
+
+   CGA verification takes an IPv6 address and a CGA Parameters data
+   structure as input.  The CGA Parameters consist of the concatenated
+   modifier, subnet prefix, collision count, public key, and optional
+   extension fields.  The verification either succeeds or fails.
+
+   The CGA MUST be verified with the following steps:
+
+   1. Check that the collision count in the CGA Parameters data
+      structure is 0, 1, or 2.  The CGA verification fails if the
+      collision count is out of the valid range.
+
+   2. Check that the subnet prefix in the CGA Parameters data structure
+      is equal to the subnet prefix (i.e., the leftmost 64 bits) of the
+      address.  The CGA verification fails if the prefix values differ.
+
+   3. Execute the SHA-1 algorithm on the CGA Parameters data structure.
+      Take the 64 leftmost bits of the SHA-1 hash value.  The result is
+      Hash1.
+
+   4. Compare Hash1 with the interface identifier (i.e., the rightmost
+      64 bits) of the address.  Differences in the three leftmost bits
+      and in bits 6 and 7 (i.e., the "u" and "g" bits) are ignored.  If
+      the 64-bit values differ (other than in the five ignored bits),
+      the CGA verification fails.
+
+   5. Read the security parameter Sec from the three leftmost bits of
+      the 64-bit interface identifier of the address.  (Sec is an
+      unsigned 3-bit integer.)
+
+   6. Concatenate from left to right the modifier, 9 zero octets, the
+      public key, and any extension fields that follow the public key in
+      the CGA Parameters data structure.  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 not zero, the CGA verification fails.  Otherwise, the
+      verification succeeds.  (If Sec=0, the CGA verification never
+      fails at this step.)
+
+   If the verification fails at any step, the execution of the algorithm
+   MUST be stopped immediately.  On the other hand, if the verification
+   succeeds, the verifier knows that the public key in the CGA
+   Parameters is the authentic public key of the address owner.  The
+
+
+
+
+
+Aura                        Standards Track                     [Page 9]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+   verifier can extract the public key by removing 25 octets from the
+   beginning of the CGA Parameters and by decoding the following
+   SubjectPublicKeyInfo data structure.
+
+   Note that the values of bits 6 and 7 (the "u" and "g" bits) of the
+   interface identifier are ignored during CGA verification.  In the
+   SEND protocol, 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 in the SEND
+   protocol SHOULD NOT have any security policy that differentiates
+   between addresses based on the value of Sec.  That way, the address
+   generator is free to choose any value of Sec.
+
+   All nodes that implement CGA verification MUST be able to process all
+   security parameter values Sec = 0, 1, 2, 3, 4, 5, 6, 7.  The
+   verification procedure is relatively fast and always requires at most
+   two computations of the SHA-1 hash function.  If Sec=0, the
+   verification never fails in steps 6 - 7 and these steps can be
+   skipped.
+
+   Nodes that implement CGA verification for SEND SHOULD be able to
+   process RSA public keys that have the algorithm identifier
+   rsaEncryption and, key length between 384 and 2,048 bits.
+   Implementations MAY support longer keys.  Future versions of this
+   specification may recommend support for longer keys.
+
+   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.
+
+6.  CGA Signatures
+
+   This section defines the procedures for generating and verifying CGA
+   signatures.  To sign a message, a node needs the CGA, the associated
+   CGA Parameters data structure, the message, and the private
+   cryptographic key that corresponds to the public key in the CGA
+   Parameters.  The node also must have a 128-bit type tag for the
+   message from the CGA Message Type name space.
+
+   To sign a message, a node SHOULD do the following:
+
+   o  Concatenate the 128-bit type tag (in network byte order) and the
+      message with the type tag to the left and the message to the
+      right.  The concatenation is the message to be signed in the next
+      step.
+
+
+
+Aura                        Standards Track                    [Page 10]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+   o  Generate the RSA signature by using the RSASSA-PKCS1-v1_5
+      [RFC3447] signature algorithm with the SHA-1 hash algorithm.  The
+      private key and the concatenation created above are the inputs to
+      the generation operation.
+
+   The SEND protocol specification [RFC3971] defines several messages
+   that contain a signature in the Signature Option.  The SEND protocol
+   specification also defines a type tag from the CGA Message Type name
+   space.  The same type tag is used for all the SEND messages that have
+   the Signature Option.  This type tag is an IANA-allocated 128 bit
+   integer that has been chosen at random to prevent an accidental type
+   collision with messages of other protocols that use the same public
+   key but that may or may not use IANA-allocated type tags.
+
+   The CGA, the CGA Parameters data structure, the message, and the
+   signature are sent to the verifier.  The SEND protocol specification
+   defines how these data items are sent in SEND protocol messages.
+   Note that the 128-bit type tag is not included in the SEND protocol
+   messages because the verifier knows its value implicitly from the
+   ICMP message type field in the SEND message.  See the SEND
+   specification [RFC3971] for precise information about how SEND
+   handles the type tag.
+
+   To verify a signature, the verifier needs the CGA, the associated CGA
+   Parameters data structure, the message, and the signature.  The
+   verifier also needs to have the 128-bit type tag for the message.
+
+   To verify the signature, a node SHOULD do the following:
+
+   o  Verify the CGA as defined in Section 5.  The inputs to the CGA
+      verification are the CGA and the CGA Parameters data structure.
+
+   o  Concatenate the 128-bit type tag and the message with the type tag
+      to the left and the message to the right.  The concatenation is
+      the message whose signature is to be verified in the next step.
+
+   o  Verify the RSA signature by using the RSASSA-PKCS1-v1_5 [RFC3447]
+      algorithm with the SHA-1 hash algorithm.  The inputs to the
+      verification operation are the public key (i.e., the RSAPublicKey
+      structure from the SubjectPublicKeyInfo structure that is a part
+      of the CGA Parameters data structure), the concatenation created
+      above, and the signature.
+
+   The verifier MUST accept the signature as authentic only if both the
+   CGA verification and the signature verification succeed.
+
+
+
+
+
+
+Aura                        Standards Track                    [Page 11]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+7.  Security Considerations
+
+7.1.  Security Goals and Limitations
+
+   The purpose of CGAs is to prevent stealing and spoofing of existing
+   IPv6 addresses.  The public key of the address owner is bound
+   cryptographically to the address.  The address owner can use the
+   corresponding private key to assert its ownership and to sign SEND
+   messages sent from the address.
+
+   It is important to understand that an attacker can create a new
+   address from an arbitrary subnet prefix and its own (or someone
+   else's) public key because CGAs are not certified.  However, the
+   attacker cannot impersonate somebody else's address.  This is because
+   the attacker would have to find a collision of the cryptographic hash
+   value Hash1.  (The property of the hash function needed here is
+   called second pre-image resistance [MOV97].)
+
+   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, and the verifier ignores the values
+   of the "u" and "g" bits.  In SEND, this does not have any security or
+   implementation implications.
+
+   Another limitation of CGAs is that there is no mechanism for proving
+   that an address is not a CGA.  Thus, an attacker could take someone
+   else's CGA and present it as a non-cryptographically generated
+   address (e.g., as an RFC 3041 address [RFC3041]).  An attacker does
+   not benefit from this because although SEND nodes accept both signed
+   and unsigned messages from every address, they give priority to the
+   information in the signed messages.
+
+   The minimum RSA key length required for SEND is only 384 bits.  So
+   short keys are vulnerable to integer-factoring attacks and cannot be
+   used for strong authentication or secrecy.  On the other hand, the
+   cost of factoring 384-bit keys is currently high enough to prevent
+   most denial-of-service attacks.  Implementations that initially use
+   short RSA keys SHOULD be prepared to switch to longer keys when
+   denial-of-service attacks arising from integer factoring become a
+   problem.
+
+   The impact of a key compromise on CGAs depends on the application for
+   which they are used.  In SEND, it is not a major concern.  If the
+   private signature key is compromised because the SEND node has itself
+   been compromised, the attacker does not need to spoof SEND messages
+   from the node.  When it is discovered that a node has been
+   compromised, a new signature key and a new CGA SHOULD be generated.
+
+
+
+Aura                        Standards Track                    [Page 12]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+   On the other hand, if the RSA key is compromised because integer-
+   factoring attacks for the chosen key length have become practical,
+   the key has to be replaced with a longer one, as explained above.  In
+   either case, the address change effectively revokes the old public
+   key.  It is not necessary to have any additional key revocation
+   mechanism or to limit the lifetimes of the signature keys.
+
+7.2.  Hash Extension
+
+   As computers become faster, the 64 bits of the interface identifier
+   will not be sufficient to prevent attackers from searching for hash
+   collisions.  It helps somewhat that we include the subnet prefix of
+   the address in the hash input.  This prevents the attacker from using
+   a single pre-computed database to attack addresses with different
+   subnet prefixes.  The attacker needs to create a separate database
+   for each subnet prefix.  Link-local addresses are, however, left
+   vulnerable because the same prefix is used by all IPv6 nodes.
+
+   To prevent the CGA technology from becoming outdated as computers
+   become faster, the hash technique used to generate CGAs must be
+   extended somehow.  The chosen extension technique is to increase the
+   cost of both address generation and brute-force attacks by the same
+   parameterized factor while keeping the cost of address use and
+   verification constant.  This also provides protection for link-local
+   addresses.  Introduction of the hash extension is the main difference
+   between this document and earlier CGA proposals [OR01][Nik01][MC02].
+
+   To achieve the effective extension of the hash length, the input to
+   the second hash function, Hash2, is modified (by changing the
+   modifier value) until the leftmost 16*Sec bits of the hash value are
+   zero.  This increases the cost of address generation approximately by
+   a factor of 2^(16*Sec).  It also increases the cost of brute-force
+   attacks by the same factor.  That is, the cost of creating a CGA
+   Parameters data structure that binds the attacker's public key with
+   somebody else's address is increased from O(2^59) to
+   O(2^(59+16*Sec)).  The address generator may choose the security
+   parameter Sec depending on its own computational capacity, the
+   perceived risk of attacks, and the expected lifetime of the address.
+   Currently, Sec values between 0 and 2 are sufficient for most IPv6
+   nodes.  As computers become faster, higher Sec values will slowly
+   become useful.
+
+   Theoretically, if no hash extension is used (i.e., Sec=0) and a
+   typical attacker is able to tap into N local networks at the same
+   time, an attack against link-local addresses is N times as efficient
+   as an attack against addresses of a specific network.  The effect
+   could be countered by using a slightly higher Sec value for link-
+
+
+
+
+Aura                        Standards Track                    [Page 13]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+   local addresses.  When higher Sec values (such that 2^(16*Sec) > N)
+   are used for all addresses, the relative advantage of attacking
+   link-local addresses becomes insignificant.
+
+   The effectiveness of the hash extension depends on the assumption
+   that the computational capacities of the attacker and the address
+   generator will grow at the same (potentially exponential) rate.  This
+   is not necessarily true if the addresses are generated on low-end
+   mobile devices, for which the main design goals are to lower cost and
+   decrease size, rather than increase computing power.  But there is no
+   reason for doing so.  The expensive part of the address generation
+   (steps 1 - 3 of the generation algorithm) may be delegated to a more
+   powerful computer.  Moreover, this work can be done in advance or
+   offline, rather than in real time, when a new address is needed.
+
+   To make it possible for mobile nodes whose subnet prefixes change
+   frequently to use Sec values greater than zero, we have decided not
+   to include the subnet prefix in the input of Hash2.  The result is
+   weaker than it would be if the subnet prefix were included in the
+   input of both hashes.  On the other hand, our scheme is at least as
+   strong as using the hash extension technique without including the
+   subnet prefix in either hash.  It is also at least as strong as not
+   using the hash extension but including the subnet prefix.  This
+   trade-off was made because mobile nodes frequently move to insecure
+   networks, where they are at the risk of denial-of-service (DoS)
+   attacks (for example, during the duplicate address detection
+   procedure).
+
+   In most networks, the goal of Secure Neighbor Discovery and CGA
+   signatures is to prevent denial-of-service attacks.  Therefore, it is
+   usually sensible to start by using a low Sec value and to replace
+   addresses with stronger ones only when denial-of-service attacks
+   based on brute-force search become a significant problem.  If CGAs
+   were used as a part of a strong authentication or secrecy mechanism,
+   it might be necessary to start with higher Sec values.
+
+   The collision count value is used to modify the input to Hash1 if
+   there is an address collision.  It is important not to allow
+   collision count values higher than 2.  First, it is extremely
+   unlikely that three collisions would occur and the reason is certain
+   to be either a configuration or implementation error or a denial-of-
+   service attack.  (When the SEND protocol is used, deliberate
+   collisions caused by a DoS attacker are detected and ignored.)
+   Second, an attacker doing a brute-force search to match a given CGA
+   can try all different values of a collision count without repeating
+   the brute-force search for the modifier value.  Thus, if higher
+   values are allowed for the collision count, the hash extension
+   technique becomes less effective in preventing brute force attacks.
+
+
+
+Aura                        Standards Track                    [Page 14]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+7.3.  Privacy Considerations
+
+   CGAs can give the same level of pseudonymity as the IPv6 address
+   privacy extensions defined in RFC 3041 [RFC3041].  An IP host can
+   generate multiple pseudo-random CGAs by executing the CGA generation
+   algorithm of Section 4 multiple times and by using a different random
+   or pseudo-random initial value for the modifier every time.  The host
+   should change its address periodically as in [RFC3041].  When privacy
+   protection is needed, the (pseudo)random number generator used in
+   address generation SHOULD be strong enough to produce unpredictable
+   and unlinkable values.  Advice on random number generation can be
+   found in [RFC1750].
+
+   There are two apparent limitations to this privacy protection.
+   However, as will be explained below, neither is very serious.
+
+   First, the high cost of address generation may prevent hosts that use
+   a high Sec value from changing their address frequently.  This
+   problem is mitigated because the expensive part of the address
+   generation may be done in advance or offline, as explained in the
+   previous section.  It should also be noted that the nodes that
+   benefit most from high Sec values (e.g., DNS servers, routers, and
+   data servers) usually do not require pseudonymity, and the nodes that
+   have high privacy requirements (e.g., client PCs and mobile hosts)
+   are unlikely targets for expensive brute-force DoS attacks and can
+   make do with lower Sec values.
+
+   Second, the public key of the address owner is revealed in the signed
+   SEND messages.  This means that if the address owner wants to be
+   pseudonymous toward the nodes in the local links that it accesses, it
+   should generate not only a new address but also a new public key.
+   With typical local-link technologies, however, a node's link-layer
+   address is a unique identifier for the node.  As long as the node
+   keeps using the same link-layer address, it makes little sense to
+   change the public key for privacy reasons.
+
+7.4.  Related Protocols
+
+   Although this document defines CGAs only for the purposes of Secure
+   Neighbor Discovery, other protocols could be defined elsewhere that
+   use the same addresses and public keys.  This raises the possibility
+   of related-protocol attacks in which a signed message from one
+   protocol is replayed in another protocol.  This means that other
+   protocols (perhaps even those designed without an intimate knowledge
+   of SEND) could endanger the security of SEND.  What makes this threat
+   even more significant is that the attacker could create a CGA from
+   someone else's public key and then replay signed messages from a
+   protocol that has nothing to do with CGAs or IP addresses.
+
+
+
+Aura                        Standards Track                    [Page 15]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+   To prevent the related-protocol attacks, a type tag is prepended to
+   every message before it is signed.  The type tags are 128-bit
+   randomly chosen values, which prevents accidental type collisions
+   with even poorly designed protocols that do not use any type tags.
+   Moreover, the SEND protocol includes the sender's CGA address in all
+   signed messages.  This makes it even more difficult for an attacker
+   to take signed messages from some other context and to replay them as
+   SEND messages.
+
+   Finally, a strong cautionary note has to be made about using CGA
+   signatures for purposes other than SEND.  First, the other protocols
+   MUST include a type tag and the sender address in all signed messages
+   in the same way that SEND does.  Each protocol MUST define its own
+   type tag values as explained in Section 8.  Moreover, because of the
+   possibility of related-protocol attacks, the public key MUST be used
+   only for signing, and it MUST NOT be used for encryption.  Second,
+   the minimum RSA key length of 384 bits may be too short for many
+   applications and the impact of key compromise on the particular
+   protocol must be evaluated.  Third, CGA-based authorization is
+   particularly suitable for securing neighbor discovery [RFC2461] and
+   duplicate address detection [RFC2462] because these are network-layer
+   signaling protocols for which IPv6 addresses are natural endpoint
+   identifiers.  In any protocol that uses other identifiers, such as
+   DNS names, CGA signatures alone are not a sufficient security
+   mechanism.  There must also be a secure way of mapping the other
+   identifiers to IPv6 addresses.  If the goal is not to verify claims
+   about IPv6 addresses, CGA signatures are probably not the right
+   solution.
+
+8.  IANA Considerations
+
+   This document defines a new CGA Message Type name space for use as
+   type tags in messages that may be signed by using CGA signatures.
+   The values in this name space are 128-bit unsigned integers.  Values
+   in this name space are allocated on a First Come First Served basis
+   [RFC2434].  IANA assigns new 128-bit values directly without a
+   review.
+
+   The requester SHOULD generate the new values with a strong random-
+   number generator.  Continuous ranges of at most 256 values can be
+   requested provided that the 120 most significant bits of the values
+   have been generated with a strong random-number generator.
+
+   IANA does not generate random values for the requester.  IANA
+   allocates requested values without verifying the way in which they
+   have been generated.  The name space is essentially unlimited, and
+   any number of individual values and ranges of at most 256 values can
+   be allocated.
+
+
+
+Aura                        Standards Track                    [Page 16]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+   CGA Message Type values for private use MAY be generated with a
+   strong random-number generator without IANA allocation.
+
+   This document does not define any new values in any name space.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC3971]         Arkko, J., Ed., Kempf, J., Sommerfeld, B., Zill,
+                     B., and P. Nikander, "SEcure Neighbor Discovery
+                     (SEND)", RFC 3971, March 2005.
+
+   [RFC3279]         Bassham, L., Polk, W., and R. Housley, "Algorithms
+                     and Identifiers for the Internet X.509 Public Key
+                     Infrastructure Certificate and Certificate
+                     Revocation List (CRL) Profile", RFC 3279, April
+                     2002.
+
+   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
+                     Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3513]         Hinden, R. and S. Deering, "Internet Protocol
+                     Version 6 (IPv6) Addressing Architecture", RFC
+                     3513, April 2003.
+
+   [RFC3280]         Housley, R., Polk, W., Ford, W., and D. Solo,
+                     "Internet X.509 Public Key Infrastructure
+                     Certificate and Certificate Revocation List (CRL)
+                     Profile", RFC 3280, April 2002.
+
+   [ITU.X690.2002]   International Telecommunications Union,
+                     "Information Technology - ASN.1 encoding rules:
+                     Specification of Basic Encoding Rules (BER),
+                     Canonical Encoding Rules (CER) and Distinguished
+                     Encoding Rules (DER)", ITU-T Recommendation X.690,
+                     July 2002.
+
+   [RFC3447]         Jonsson, J. and B. Kaliski, "Public-Key
+                     Cryptography Standards (PKCS) #1: RSA Cryptography
+                     Specifications Version 2.1", RFC 3447, February
+                     2003.
+
+   [RFC2434]         Narten, T. and H. Alvestrand, "Guidelines for
+                     Writing an IANA Considerations Section in RFCs",
+                     BCP 26, RFC 2434, October 1998.
+
+
+
+
+
+Aura                        Standards Track                    [Page 17]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+   [FIPS.180-1.1995] National Institute of Standards and Technology,
+                     "Secure Hash Standard", Federal Information
+                     Processing Standards Publication FIPS PUB 180-1,
+                     April 1995,
+                     <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
+
+9.2.  Informative References
+
+   [AAKMNR02]        Arkko, J., Aura, T., Kempf, J., Mantyla, V.,
+                     Nikander, P., and M. Roe, "Securing IPv6 neighbor
+                     discovery and router discovery", ACM Workshop on
+                     Wireless Security (WiSe 2002), Atlanta, GA USA ,
+                     September 2002.
+
+   [Aura03]          Aura, T., "Cryptographically Generated Addresses
+                     (CGA)", 6th Information Security Conference
+                     (ISC'03), Bristol, UK, October 2003.
+
+   [RFC1750]         Eastlake, D., Crocker, S., and J. Schiller,
+                     "Randomness Recommendations for Security", RFC
+                     1750, December 1994.
+
+   [MOV97]           Menezes, A., van Oorschot, P., and S. Vanstone,
+                     "Handbook of Applied Cryptography", CRC Press ,
+                     1997.
+
+   [MC02]            Montenegro, G. and C. Castelluccia, "Statistically
+                     unique and cryptographically verifiable identifiers
+                     and addresses", ISOC Symposium on Network and
+                     Distributed System Security (NDSS 2002), San Diego,
+                     CA USA , February 2002.
+
+   [RFC3041]         Narten, T. and R. Draves, "Privacy Extensions for
+                     Stateless Address Autoconfiguration in IPv6", RFC
+                     3041, January 2001.
+
+   [RFC2461]         Narten, T., Nordmark, E., and W. Simpson, "Neighbor
+                     Discovery for IP Version 6 (IPv6)", RFC 2461,
+                     December 1998.
+
+   [Nik01]           Nikander, P., "A scaleable architecture for IPv6
+                     address ownership", draft-nikander-addr-ownership-
+                     00 (work in progress), March 2001.
+
+   [OR01]            O'Shea, G. and M. Roe, "Child-proof authentication
+                     for MIPv6 (CAM)", ACM Computer Communications
+                     Review 31(2), April 2001.
+
+
+
+
+Aura                        Standards Track                    [Page 18]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+   [RFC2462]         Thomson, S. and T. Narten, "IPv6 Stateless Address
+                     Autoconfiguration", RFC 2462, December 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aura                        Standards Track                    [Page 19]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+Appendix A.  Example of CGA Generation
+
+   We generate a CGA with Sec=1 from the subnet prefix fe80:: and the
+   following public key:
+
+   305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241
+   00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16
+   467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773
+   c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
+
+   The modifier is initialized to a random value 89a8 a8b2 e858 d8b8
+   f263 3f44 d2d4 ce9a.  The input to Hash2 is:
+
+   89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9a 0000 0000 0000 0000 00
+   305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241
+   00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16
+   467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773
+   c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
+
+   The 112 first bits of the SHA-1 hash value computed from the above
+   input are Hash2=436b 9a70 dbfd dbf1 926e 6e66 29c0.  This does not
+   begin with 16*Sec=16 zero bits.  Thus, we must increment the modifier
+   by one and recompute the hash.  The new input to Hash2 is:
+
+   89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9b 0000 0000 0000 0000 00
+   305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241
+   00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16
+   467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773
+   c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
+
+   The new hash value is Hash2=0000 01ca 680b 8388 8d09 12df fcce.  The
+   16 leftmost bits of Hash2 are all zero.  Thus, we found a suitable
+   modifier.  (We were very lucky to find it so soon.)
+
+   The input to Hash1 is:
+
+   89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9b fe80 0000 0000 0000 00
+   305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241
+   00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16
+   467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773
+   c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
+
+   The 64 first bits of the SHA-1 hash value of the above input are
+   Hash1=fd4a 5bf6 ffb4 ca6c.  We form an interface identifier from this
+   by writing Sec=1 into the three leftmost bits and by setting bits 6
+   and 7 (the "u" and "g" bits) to zero.  The new interface identifier
+   is 3c4a:5bf6:ffb4:ca6c.
+
+
+
+
+Aura                        Standards Track                    [Page 20]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+   Finally, we form the IPv6 address fe80::3c4a:5bf6:ffb4:ca6c.  This is
+   the new CGA.  No address collisions were detected this time.
+   (Collisions are very rare.)  The CGA Parameters data structure
+   associated with the address is the same as the input to Hash1 above.
+
+Appendix B.  Acknowledgements
+
+   The author gratefully acknowledges the contributions of Jari Arkko,
+   Francis Dupont, Pasi Eronen, Christian Huitema, James Kempf, Pekka
+   Nikander, Michael Roe, Dave Thaler, and other participants of the
+   SEND working group.
+
+Author's Address
+
+   Tuomas Aura
+   Microsoft Research
+   Roger Needham Building
+   7 JJ Thomson Avenue
+   Cambridge  CB3 0FB
+   United Kingdom
+
+   Phone: +44 1223 479708
+   EMail: tuomaura@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aura                        Standards Track                    [Page 21]
+
+RFC 3972         Cryptographically Generated Addresses        March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Aura                        Standards Track                    [Page 22]
+