IETF Securing Neighbor Discovery WG                      Tuomas Aura
INTERNET DRAFT                                    Microsoft Research
Expires December 2003                                      June 2003

            Cryptographically Generated Addresses (CGA)
                    draft-ietf-send-cga-00.txt

Status of This Memo

  This document is an Internet-Draft and is in full conformance with
  all provisions of Section 10 of RFC2026. Internet-Drafts are
  working documents of the Internet Engineering Task Force (IETF),
  its areas, and its working groups. Note that other groups may also
  distribute working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six
  months and may be updated, replaced, or obsoleted by other
  documents at any time. It is inappropriate to use Internet-Drafts
  as reference material or to cite them other than as "work in
  progress."

  The list of current Internet-Drafts can be accessed at
            http://www.ietf.org/ietf/1id-abstracts.txt
  The list of Internet-Draft Shadow Directories can be accessed at
                 http://www.ietf.org/shadow.html.

  This Internet-Draft will expire on December 13, 2003.

Copyright Notice

  Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

  This document describes a method for binding a public signature key
  to an IPv6 address in Secure Neighbor Discovery (SEND).
  Cryptographically Generated Addresses (CGA) are IPv6 addresses
  where the interface identifier is generated by computing a
  cryptographic one-way hash function from the address owner's 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. SEND protocol
  messages are protected with an Authentication Header (AH) that
  contains the public key and the auxiliary parameters and is signed
  with the corresponding private key. The protection works without a
  certification authority or other security infrastructure.

Table of Contents



Aura                Expires December 13, 2003             [Page 1]


INTERNET-DRAFT   Cryptographically Generated Addresses (CGA) June 2003

Status of This Memo...............................................1
Copyright Notice..................................................1
Abstract..........................................................1
Table of Contents.................................................1
1. Introduction...................................................2
2. The CGA Address Format.........................................3
3. The CGA Parameters and the Hash Values.........................4
4. CGA Generation.................................................5
5. CGA Verification...............................................6
6. The CGA Authorization Mechanism for SEND.......................8
 6.1 Sending SEND Messages........................................8
 6.2 Receiving SEND messages......................................9
7. Security Considerations........................................9
 7.1 Security Goals and Limitations...............................9
 7.2 Hash extension..............................................10
 7.3 Privacy Considerations......................................12
8. IANA Considerations...........................................13
Acknowledgments..................................................13
Intellectual Property Statement..................................13
Normative References.............................................13
Informative References...........................................14
Appendix A.   Example of CGA Generation..........................14
Appendix B.   Changes since draft-aura-cga-pre01.................14
Author's Address.................................................15
Intellectual Property Statement..................................15
Full Copyright Statement.........................................15

1. Introduction

  This document specifies a method for securely associating a public
  key with an IPv6 address in the secure neighbor discovery (SEND)
  protocol [AKSZ03]. The basic idea is to generate the interface
  identifier (i.e. rightmost 64 bits) of the IPv6 address by
  computing a cryptographic hash of the public key. This kind of IPv6
  addresses are called cryptographically generated addresses (CGA).
  The corresponding private key can then be used to sign SEND
  messages.

  More specifically, this document specifies

     - how to create CGA addresses from the cryptographic hash of a
        public key and auxiliary parameters,

     - how to transfer the public key and the auxiliary parameters
        in a signed SEND message, and

     - how to verify the association between the public key and the
        IPv6 address.



Aura                Expires December 13, 2003             [Page 2]


INTERNET-DRAFT   Cryptographically Generated Addresses (CGA) June 2003

  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.

  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 a method for authenticating SEND messages where
  the source address is a CGA address.

  The security considerations in Section 7 include limitations of
  CGA-based authentication, the reasoning behind the hash extension
  technique that enables effective hash lengths above the 64-bit
  limit of the interface identifier, and the implications CGA
  addresses on privacy.

  The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
  SHOULD NOT, RECOMMENDED,  MAY, and OPTIONAL in this document are to
  be interpreted as described in [Bra97].

2. The CGA Address Format

  When talking about addresses, this document refers to IPv6
  addresses where 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. [HD03]

  A cryptographically generated address (CGA) has a security
  parameter (Sec), which determines its strength against brute-force
  attacks. The security parameter is a 3-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:

      Sec = (interface identifier & 0xe000000000000000) >> 61

  The CGA address is associated with a set of parameters, which
  consist of a public key and auxiliary parameters. Two hash values
  Hash1 and Hash2 (64 and 112 bits, respectively) are computed from
  the parameters. The formats of the public key and auxiliary
  parameters and the inputs to the hash functions are defined in
  Section 3.

  A cryptographically generated address (CGA) is defined as an IPv6
  address where the 16*Sec leftmost bits of the second hash value
  Hash2 are zero, and the rightmost 64 bits of the first hash value
  Hash1 equal the interface identifier of the address. The three


Aura                Expires December 13, 2003             [Page 3]


INTERNET-DRAFT   Cryptographically Generated Addresses (CGA) June 2003

  leftmost bits of the address, which encode the security parameter
  Sec, and the "u" and "g" bits are ignored in the comparison. The
  "u" and "g" bits (i.e. bits 6 and 7 of the interface identifier)
  must both be zero.

  The above definition can be stated in terms of the following two
  bit masks:

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

    Mask2 (64 bits)  = 0xfcfffffffffffff8

    Mask3 (64 bits)  = 0xfffffffffffffff8

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

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

3. The CGA Parameters and the Hash Values

  Each CGA address is associated with a DER-encoded [ITU02] ASN.1
  data item of the type CGAParameters:

               CGAParameters ::= SEQUENCE {
                 auxParameters  CGAAuxParameters,
                 publicKey      SubjectPublicKeyInfo }

               CGAAuxParameters ::= SEQUENCE {
                 modifier       OCTET STRING (SIZE 16),
                 subnetPrefix   OCTET STRING (SIZE 8),
                 collisionCount INTEGER (0..2) }

  The publicKey data item contains the address owner's public key.
  The ASN.1 type SubjectPublicKeyInfo is defined in the Internet
  X.509 certificate profile [HFPS02]. In addition to the public key,
  there are three auxiliary parameters:

     o a 16-octet modifier, which can get any value




Aura                Expires December 13, 2003             [Page 4]


INTERNET-DRAFT   Cryptographically Generated Addresses (CGA) June 2003

     o the 8-octet subnetPrefix, which is equal to the subnet prefix
        of the CGA address, and

     o collisionCount, which can get values 0, 1 and 2.

  The two hash values are computed with the SHA-1 hash algorithm
  [NIS95] from the DER-encoded CGAParameters data item. When
  computing Hash1, the input to the SHA-1 algorithm is simply the
  DER-encoding. The 64-bit Hash1 is obtained by taking the leftmost
  64 bits of then 160-bit SHA-1 hash value.

  When computing Hash2, the value of the subnetPrefix data item is
  set to 8 zero octets and the value of the collisionCount data item
  is set to 0. The 112-bit Hash1 is obtained by taking the leftmost
  112 bits of the 160-bit SHA-1 hash value.

4. CGA Generation

  The process of generating a new CGA address takes three input
  values: a 64-bit subnet prefix, the public key of the address
  owner, and the security parameter Sec, which is an unsigned 3-bit
  integer. The result is a new CGA address and the associated
  parameters. The cost of generating a new CGA address depends on the
  security parameter Sec, which gets values from 0 to 7.

  A CGA address and associated CGA parameters SHOULD be generated as
  follows:

    (1)  Create an ASN.1 data item of type CGAParameters. Set the
         publicKey data value to the address owner's public key. Set
         the modifier data value to 16 random octets. Set the
         subnetPrefix data value to 8 zero octets. Set the
         collisionCount data value to zero.

    (2)  DER-encode the CGAParameters data value. Execute the SHA-1
         algorithm on the DER-encoded CGAParameters data value. 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 the step (4).
         Otherwise, increment the modifier data value (as if its
         content octets were a 128-bit integer) and go back to step
         (2).

    (4)  Set the 8-octet subnetPrefix data value in the encoded
         CGAParameters data item to the given subnet prefix.




Aura                Expires December 13, 2003             [Page 5]


INTERNET-DRAFT   Cryptographically Generated Addresses (CGA) June 2003

    (5)  Execute the SHA-1 algorithm on the new DER-encoded
         CGAParameters data value. Take the 64 leftmost bits of the
         SHA-1 hash value. The result is Hash1.

    (6)  Form an EUI-64 interface identifier by setting the "u" and
         "g" bits in Hash1 both to 0 and the three leftmost bits of
         the address to the value Sec.

    (7)  Concatenate the 64-bit subnet prefix and the EUI-64
         interface identifier to form a 128-bit IPv6 address.

    (8)  If an address collision is detected, increment the
         collisionCount data value in the DER-encoded CGAParameters
         data item and go back to step (5). However, after three
         collisions, stop and report the error.

  In order to avoid trying the same modifier values repeatedly, it is
  RECOMMENDED to that the initial modifier value in step (1) is
  chosen randomly and that the modifier is incremented in step (3) as
  if it were an unsigned 128-bit integer. When incrementing the
  modifier, the octet order can be chosen arbitrarily and overflows
  can be ignored. The quality of the random number generator is not
  important as long as the same values are not repeated frequently.
  However, if privacy enhancement (see Section 7.3) is required, the
  random numbers should be unpredictable and unlinkable.

  For Sec=0, the above algorithm is deterministic and relatively
  fast. Nodes that implement CGA generation MAY set the security
  parameter Sec to always 0. In that case, steps (2)-(3) of the
  generation algorithm can be skipped.

  For Sec values greater than 0, 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. Implementations SHOULD take into account the fact that
  generating CGA addresses with high Sec values will take
  considerable time and that generating addresses with the highest
  Sec values is infeasible with today's technology.

  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 avoids
  repeating the expensive search for an acceptable modifier value.

5. CGA Verification

  CGA verification takes two inputs: an IPv6 address and a DER-
  encoded CGAParameters data item. The verification either succeeds
  or fails.


Aura                Expires December 13, 2003             [Page 6]


INTERNET-DRAFT   Cryptographically Generated Addresses (CGA) June 2003


  The CGA MUST be verified with the following steps:

    (1)  Check that the "g" and "u" bits in the interface identifier
         are both zero. If either bit is non-zero, the CGA
         verification fails.

    (2)  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.)

    (3)  Decode the DER-encoded CGAParameters data item. Check that
         the subnetPrefix data value is equal to the subnet prefix
         (i.e. leftmost 64 bits) of the address. Check that the
         collisionCount value is 0, 1 or 2. The CGA verification
         fails if the decoding of the CGA parameters fails, if the
         subnetPrefix value does not match the address, or if the
         collisionCount value is out of range.

    (4)  Execute the SHA-1 algorithm on the DER-encoded CGAParameters
         data value. Take the 64 leftmost bits of the SHA-1 hash
         value. The result is Hash1.

    (5)  Compare Hash1 with the interface identifier (i.e. the
         rightmost 64 bits) of the address. Differences in the "g"
         and "u" bits and in the three leftmost bits are ignored. If
         the 64-bit values differ (other than in the five ignored
         bits), the CGA verification fails.

    (6)  Set the subnetPrefix data value in the DER-encoded
         CGAParameters data item to 8 zero octets and the
         collisionCount data value to 0.

    (7)  Execute the SHA-1 algorithm on the new DER-encoded
         CGAParameters data value. Take the 112 leftmost bits of the
         SHA-1 hash value. The result is Hash2.

    (8)  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.)

  If the verification succeeds, the verifier knows that the publicKey
  field in the CGAParameters data value is the authentic public key
  of the address owner.

  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 a


Aura                Expires December 13, 2003             [Page 7]


INTERNET-DRAFT   Cryptographically Generated Addresses (CGA) June 2003

  constant amount of computation. If Sec=0, the verification never
  fails in steps (6)-(8) and these steps MAY be skipped.

  After the verification succeeds or fails, the verifier SHOULD
  discard the Sec, modifier and collisionCount values and not use
  them for any further purpose. In particular, the verifier should
  set the minSec value in the inbound AH_RSA_Sig security association
  to zero (see [AKSZ03] Section 7.1.3). Future extensions of this
  specification may define situations where a it is acceptable for
  the verifier to set higher minSec values.

6. The CGA Authorization Mechanism for SEND

  Nodes that use Secure Neighbor Discovery (SEND) protocol MUST
  process outbound and inbound SEND messages as specified in
  [AKSZ03]. This section gives additional guidance on using the CGA
  authorization mechanism in these messages.

6.1 Sending SEND Messages

  sNodes that use the Secure Neighbor Discovery (SEND) protocol and
  use CGA addresses MUST use the format of the CGA addresses as
  described in Section 2, SHOULD generate the addresses as described
  in Section 4.

  The public key used for the address generation MUST have the object
  identifier sha1WithRSAEncryption [JK03]. The RSA public key MUST be
  at least 1024 bits long.

  A node that has a CGA address MAY use the CGA authorization
  mechanism when it sends secure Neighbor Solicitations (NS),
  Neighbor Advertisements (NA), Router Solicitations (RS) and Router
  Advertisements (RA) where the IP source address is a CGA address
  and the source link-layer address option is present in the message.
  Note that the node MAY use trusted-root authorization mechanism
  instead or in addition to the CGA authorization mechanism
  authentication. The mechanism to be used is determined by the
  node's IPSec configuration.

  When sending a secure NA, NS, RA or RS message, the node MUST
  protect the message with an IPSec Authentication Header (AH) that
  uses the AH_RSA_Sig transform defined in [AKSZ03]. Within the AH,
  the contents of the Key Information field are represented as ASN.1
  DER-encoded data item of the following type:

          SendKeyInformation ::= SEQUENCE {
            cgaParameters  CGAParameters OPTIONAL,
            signerInfo     SubjectPublicKeyInfo OPTIONAL }



Aura                Expires December 13, 2003             [Page 8]


INTERNET-DRAFT   Cryptographically Generated Addresses (CGA) June 2003

  (The normative definition of the type SendKeyInformation is in
  [AKSZ03].)

  When the CGA authorization mechanism is used in a SEND message, the
  cgaParameters field in SendKeyInformation MUST be present and its
  value MUST be the same CGAParameters data value that was used for
  generating the IP source address of the SEND message. The signature
  in the AH MUST be verifiable with the public key that is sent in
  the CGAParameters.

6.2 Receiving SEND messages

  Received SEND messages MUST be processed as specified in Section
  7.1.6 of [AKSZ03]. If the security association requires the
  verification of the CGA property, the receiver must verify the MUST
  verify the source address of the packet as described in Section 5.
  The inputs for the algorithm are the source address of the packet
  and the contents of the CGAParameters structure from the Key
  Information field.

  If the CGA verification is successful, the node goes on to verify
  the signature in the AH as defined in [AKSZ03]. On the other hand,
  if the CGA verification fails, the recipient MUST stop processing
  the SEND message and ignore its contents.

7. Security Considerations

7.1 Security Goals and Limitations

  The purpose of CGA addresses is to prevent stealing and spoofing of
  IPv6 addresses in the secure neighbor discovery protocol. 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 of the address and to sign SEND messages sent
  from the address.

  It is important to understand that that attacker can create a new
  address from an arbitrary subnet prefix and its own public key.
  What the attacker cannot do is to 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
  or weak collision resistance.)

  For each valid CGAParameters data value, there are Sec different
  CGA addresses 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. In SEND, this fact does
  not have any security or implementation implications.


Aura                Expires December 13, 2003             [Page 9]


INTERNET-DRAFT   Cryptographically Generated Addresses (CGA) June 2003


  Another limitation of CGA addresses is that there is no mechanism
  for proving that an address is not a CGA address. Thus, an attacker
  could take someone else's CGA address and present it as a non-CGA
  address (e.g. as an RFC-3041 address). To avoid being tricked,
  every node must either accept neighbor discovery messages with CGA-
  based authentication or unauthenticated ones, but not both. This
  effectively means that secure and insecure nodes on the same
  network cannot talk directly to each other. Nodes can, however, be
  configured to use different subnet prefixes for CGA and non-CGA
  addresses.

  Finally, a cautionary note should be made about using CGA-based
  authentication for other purposes than SEND. CGA-based
  authentication is particularly suitable for securing neighbor
  discovery [NN98] and duplicate address detection [TN98] because
  these are network-layer signaling protocols where IPv6 addresses
  are natural endpoint identifiers. In any protocol that aims to
  protect higher-layer data, CGA-based authentication alone is not
  sufficient but there must also be a secure mechanism for mapping
  higher-layer identifiers, such as DNS names, to IP addresses.

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 subnet prefix is used by all IPv6
  nodes.

  In the long term, some kind of hash extension technique must be
  used to counter the effect of faster computers. Otherwise, the CGA
  technology could become outdated after 5-20 years. The idea in this
  document 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 provides
  protection also 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 Hash2 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


Aura                Expires December 13, 2003            [Page 10]


INTERNET-DRAFT   Cryptographically Generated Addresses (CGA) June 2003

  attacks by the same factor. That is, the cost of creating a
  certificate 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, 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-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 of the assumption
  that the computational capacity of the attacker and the address
  generator will grow and the same (potentially exponential) rate.
  This is clearly not true if the addresses are generated on low-end
  mobile devices. But there is no reason for doing so. The expensive
  part of the address generation (steps (2)-(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.

  In order to make it possible for mobile nodes whose subnet prefix
  changes frequently to use Sec values greater than 0, we have
  decided not to include the subnet prefix in the input of Hash2. The
  result is weaker than 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-
  based authentication 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 CGA address were used as a part of a strong
  authentication or secrecy mechanisms, it would be necessary to
  start with higher Sec values.)


Aura                Expires December 13, 2003            [Page 11]


INTERNET-DRAFT   Cryptographically Generated Addresses (CGA) June 2003


  The collisionCount value is used to modify the input to Hash1 if
  there is an address collision. It is important not to allow
  collisionCount 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, the
  deliberate collisions caused by a DoS attacker are detected and
  ignored.) Second, an attacker who is doing a brute-force search to
  match a given CGA address can try all different values of
  collisionCount without repeating the brute-force search for the
  modifier value. Thus, the more different values are allowed for
  collisionCount, the less effective the hash-extension technique is
  in preventing brute-force attacks.

7.3 Privacy Considerations

  CGA addresses can give the same level pseudonymity as the IPv6
  address privacy extensions defined in RFC 3041 [ND01]. An IP host
  can generate multiple pseudorandom CGA addresses by executing the
  CGA generation algorithm of Section 4 multiple times and by using
  every time a different random or pseudorandom initial value for the
  modifier. The host should change its address periodically as in
  [ND01]. When privacy protection is needed, the (pseudo)random
  number generator used in address generation SHOULD be strong enough
  to produce unpredictable and unlinkable values.

  There are two apparent limitations to this privacy protection.
  However, as we will explain below, neither limitation 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 by the fact that 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, while the
  nodes that have high privacy requirements (e.g. client PCs and
  mobile hosts) are unlikely targets for expensive brute-force
  attacks and can do with lower Sec values.

  Second, the public key of the address owner is revealed in the
  authenticated SEND messages. This means that if the address owner
  wants to be pseudonymous towards the nodes in the local links that
  it accesses, it should not only generate a new address but also a
  new public key. With typical local-link technologies, however, a
  node's link-layer address makes it possible for others to correlate
  its appearances of the local link. As long as the node keeps using


Aura                Expires December 13, 2003            [Page 12]


INTERNET-DRAFT   Cryptographically Generated Addresses (CGA) June 2003

  the same link-layer address, it makes little sense to ever change
  the public key for privacy reasons.

8. IANA Considerations

  No new IANA-allocated values are defined in this document.

Acknowledgments

  Many of the ideas in this draft were influenced by Michael Roe,
  Christian Huitema and Pekka Nikander. Jari Arkko, Pasi Eronen and
  other participants in the IETF working group made many helpful
  comments.

Intellectual Property Statement

  Several IPR claims have been made about the technology described in
  this document.

Normative References

  [AKSZ03]    Jari Arkko, James Kempf, Bill Sommerfeld, and Brian
  Zill. Secure neighbor discovery (SEND). Internet-Draft draft-ietf-
  send-ipsec-01.txt, IETF Securing Neighbor Discovery Working Group,
  June 2003. Work in progress.

  [Bra97] Scott Bradner. Key words for use in RFCs to indicate
  requirement levels. RFC 2119, IETF Network Working Group, March
  1997.

  [HD03] Robert M. Hinden and Stephen E. Deering. IP version 6
  addressing architecture. RFC 3513, IETF Network Working Group,
  April 2003.

  [HFPS02]    Russell Housley, Warwick Ford, Tim Polk, and David
  Solo. Internet X.509 public key infrastructure certificate and
  certificate revocation list (CRL) profile. RFC 3280, IETF Network
  Working Group, April 2002.

  [ITU02] International Telecommunication Union. ITU-T recommendation
  X.690, information technology -- ASN.1 encoding rules:
  Specification of basic encoding rules (BER), canonical encoding
  rules (CER) and distinguished encoding rules (DER), July 2002. Also
  appeared as ISO/IEC International Standard 8825-1.

  [JK03] Jakob Jonsson and Burt Kaliski. Public-key cryptography standards
  (PKCS) #1: RSA cryptography specifications version 2.1. RFC 3447, IETF
  Network Working Group, February 2003.



Aura                Expires December 13, 2003            [Page 13]


INTERNET-DRAFT   Cryptographically Generated Addresses (CGA) June 2003

  [NIS95] Secure hash standard. Federal Information Processing
  Standards Publication FIPS PUB 180-1, National Institute of
  Standards and Technology, Gaithersburg, MD USA, April 1995.

Informative References

  [AAK+02]    Jari Arkko, Tuomas Aura, James Kempf, Vesa-Matti
  M„ntyl„, Pekka Nikander, and Michael Roe. Securing IPv6 neighbor
  discovery and router discovery. In Proc. 2002 ACM Workshop on
  Wireless Security (WiSe), pages 77-86, Atlanta, GA USA, September
  2002. ACM Press.

  [MC02] Gabriel Montenegro and Claude Castelluccia. Statistically
  unique and cryptographically verifiable identifiers and addresses.
  In Proc. ISOC Symposium on Network and Distributed System Security
  (NDSS 2002), San Diego, February 2002.

  [ND01] Thomas Narten and Richard Draves. Privacy extensions for
  stateless address autoconfiguration in IPv6. RFC 3041, IETF Network
  Working Group, January 2001.

  [NN98] Thomas Narten, Erik Nordmark, and William Allen Simpson.
  Neighbor discovery for IP version 6 (IPv6). RFC 2461, IETF Network
  Working Group, December 1998.

  [Nik01] Pekka Nikander. A scaleable architecture for IPv6 address
  ownership. Internet-draft, March 2001. Work in Progress.

  [OR01] Greg O'Shea and Michael Roe. Child-proof authentication for
  MIPv6 (CAM). ACM Computer Communications Review, 31(2), April 2001.

  [TN98] Susan Thomson and Thomas Narten. IPv6 stateless address
  autoconfiguration. RFC 2462, IETF Network Working Group, December
  1998.

Appendix A.    Example of CGA Generation

  TBW

Appendix B.    Changes since draft-aura-cga-pre01

  This appendix is intended only for the readers who reviewed a
  preliminary version of this draft titled draft-aura-cga-pre01.

     o The number of zero bits in hash 2 is 16*Sec (was 12*Sec),
        length of Hash2 is 112 bits (was 84 bits), and the length of
        modifier 16 octets (was 12 octets). Makes coding easier and
        extends the maximal hash length.



Aura                Expires December 13, 2003            [Page 14]


INTERNET-DRAFT   Cryptographically Generated Addresses (CGA) June 2003

     o Sec is now encoded in the three leftmost bits of the 64-bit
        interface identifier. Earlier, it was encoded in the three
        rightmost bits. Using the rightmost bits would distort the
        distribution of solicited-node multicast addresses.

     o Changed the order of the publicKey and auxParameters fields
        in CGAParameters. This makes decoding without an ASN.1
        compiler easier because the fixed-length fields come first.

     o sha1WithRSAEncryption is now the only allowed signature
        algorithm. Minimum key length is 1024 bits. The minimum key
        length makes the decoding of CGAParameters easier.


Author's Address

  Tuomas Aura
  Microsoft Research
  7 J J Thomson Avenue
  Cambridge, CB3 0FB
  United Kingdom

  Phone: +44 1223 479708
  Email: tuomaura@microsoft.com

Intellectual Property Statement

  The IETF takes no position regarding the validity or scope of any
  intellectual property 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; neither does it represent that it
  has made any effort to identify any such rights.  Information on
  the IETF's procedures with respect to rights in standards-track and
  standards-related documentation can be found in BCP-11.  Copies of
  claims of rights made available for publication 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 Secretariat.

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights which may cover technology that may be required to practice
  this standard.  Please address the information to the IETF
  Executive Director.

Full Copyright Statement



Aura                Expires December 13, 2003            [Page 15]


INTERNET-DRAFT   Cryptographically Generated Addresses (CGA) June 2003

  Copyright (C) The Internet Society (2003).  All Rights Reserved.

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain
  it or assist in its implementation may be prepared, copied,
  published and distributed, in whole or in part, without restriction
  of any kind, provided that the above copyright notice and this
  paragraph are included on all such copies and derivative works.
  However, this document itself may not be modified in any way, such
  as by removing the copyright notice or references to the Internet
  Society or other Internet organizations, except as needed for the
  purpose of developing Internet standards in which case the
  procedures for copyrights defined in the Internet Standards process
  must be followed, or as required to translate it into languages
  other than English.

  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assigns.

  This document and the information contained herein is provided on
  an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
  ENGINEERING TASK FORCE DISCLAIMS 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.


























Aura                Expires December 13, 2003            [Page 16]