WDIFF

draft-ietf-send-cga-00.txt --> draft-ietf-send-cga-01.txt

IETF

Securing Neighbor Discovery WG Tuomas T. Aura
INTERNET DRAFT
Internet-Draft Microsoft Research
Expires December 2003 June
Expires: January 30, 2004 August 1, 2003

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

Status of This 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 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. January 30, 2004.

Abstract

This document describes a method for binding a public signature key
to an IPv6 address in the Secure Neighbor Discovery (SEND). (SEND) protocol.
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 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. SEND protocol
messages are protected with Messages sent from an Authentication Header (AH) that
contains IPv6 address can be
protected by attaching the public key and the auxiliary parameters and is signed by
signing the message with the corresponding private key. The
protection works without a certification authority or other security
infrastructure.

Table of Contents

Aura Expires December 13, 2003 January 30, 2004 [Page 1]

INTERNET-DRAFT

Internet-Draft Cryptographically Generated Addresses (CGA) June (CGA)August 2003

Status of This Memo...............................................1
Copyright Notice..................................................1
Abstract..........................................................1

Table of Contents.................................................1 Contents

1. Introduction...................................................2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The CGA Address Format.........................................3 Format . . . . . . . . . . . . . . . . . . . . . . 4
3. The CGA Parameters and the Hash Values.........................4 Values . . . . . . . . . . . . . . . . 6
4. CGA Generation.................................................5 Generation . . . . . . . . . . . . . . . . . . . . . . . . 7
5. CGA Verification...............................................6 Verification . . . . . . . . . . . . . . . . . . . . . . . 9
6. The CGA Authorization Mechanism for SEND.......................8
6.1 Sending SEND Messages........................................8
6.2 Receiving SEND messages......................................9 Signatures . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations........................................9 Considerations . . . . . . . . . . . . . . . . . . . 13
7.1 Security Goals and Limitations...............................9 Limitations . . . . . . . . . . . . . . . . 13
7.2 Hash extension..............................................10 extension . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3 Privacy Considerations......................................12 Considerations . . . . . . . . . . . . . . . . . . . . 15
7.4 Related protocols . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations...........................................13
Acknowledgments..................................................13
Intellectual Property Statement..................................13 Considerations . . . . . . . . . . . . . . . . . . . . . 17
Normative References.............................................13 References . . . . . . . . . . . . . . . . . . . . . 18
Informative References...........................................14
Appendix References . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
A. Example of CGA Generation..........................14
Appendix Generation . . . . . . . . . . . . . . . . . . 21
B. Changes since draft-aura-cga-pre01.................14
Author's Address.................................................15 draft-ietf-send-cga-00 . . . . . . . . . . . . . 23
C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property Statement..................................15
Full and Copyright Statement.........................................15 Statements . . . . . . . . 25

Aura Expires January 30, 2004 [Page 2]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

1. Introduction

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

More specifically, this messages sent from the address.

This document specifies

- specifies:

o 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

o 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 CGA
address, and

o how to generate and verify a CGA signature.

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 procedures for generating and verifying CGA address.
signatures. 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 of CGA
addresses on privacy. privacy, and protection against related-protocol
attacks.

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]. [RFC2119].

Aura Expires January 30, 2004 [Page 3]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

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] [RFC3513] We number the bits of the interface identifier
starting from bit 0 on the left.

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. (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
bits) and 112 bits, respectively) Hash2 (112 bits) are computed from the parameters. The
formats of the public key and auxiliary parameters and the inputs way to
compute the hash functions values are defined in Section 3.

A cryptographically generated address (CGA) is defined as an IPv6
address where that satisfies the following two conditions:

o The 16*Sec leftmost bits of the second hash value Hash2 are zero, and the zero.

o 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 Bits 0, 1, 2, 6 and 7 (i.e.,
the bits that encode the security parameter
Sec, Sec and the "u" and
"g" bits 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 0x1cffffffffffffff

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

Aura Expires January 30, 2004 [Page 4]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

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

Aura Expires January 30, 2004 [Page 5]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

3. The CGA Parameters and the Hash Values

Each CGA address is associated with a public key and auxiliary
parameters. The public key is formatted as a DER-encoded [ITU02]
[ITU.X690.2002] ASN.1
data item structure 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 [RFC3280]. The
public key SHOULD be an RSA encryption key with the object identifier
rsaEncryption (i.e., "1.2.840.113549.1.1.1") and the subject public key,
there
key field SHOULD be formatted as an ASN.1 data structure of the type
RSAEncryptionKey defined in [PKCS.1.1993]. The RSA key length SHOULD
be at least 384 bits. Using any other public key type or format is
strongly discouraged as it will result in incompatible CGA
implementations.

The auxiliary parameters are the following three auxiliary parameters: unsigned integers:

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

Aura Expires December 13, 2003 [Page 4]

INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003 value,

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

o collisionCount, an 8-bit collision count, which can get values 0, 1 and 2.

We use the name CGA Parameters for the data structure that is the
concatenation of the 16-octet modifier, the 8-octet subnet prefix,
the 1-octet collision count, and the variable-length encoded public
key (i.e., the SubjectPublicKeyInfo structure).

The two hash values are computed with the SHA-1 hash algorithm
[NIS95]
[FIPS.180-1.1995] from the DER-encoded CGAParameters data item. public key and auxiliary parameters. When
computing Hash1, the input to the SHA-1 algorithm is simply the
DER-encoding. CGA
Parameters data structure. The 64-bit Hash1 is obtained by taking the
leftmost 64 bits of then the 160-bit SHA-1 hash value.

When computing Hash2, the value of the subnetPrefix data item input is
set to 8 zero octets and the value of the collisionCount same CGA Parameters data item
is
structure except that the subnet prefix and collision count are set
to 0. zero. The 112-bit Hash1 Hash2 is obtained by taking the leftmost 112
bits of the 160-bit SHA-1 hash value.

Aura Expires January 30, 2004 [Page 6]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

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, owner as a
DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo, 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.

1. Set the modifier data value to 16 a random octets. Set or pseudorandom 128-bit value.

2. Concatenate the
subnetPrefix data value to 8 modifier, 9 zero octets. Set the
collisionCount data value to zero.

(2) DER-encode octets, and the CGAParameters data value. encoded public
key. Execute the SHA-1 algorithm on the DER-encoded CGAParameters data value. concatenation. Take the
112 leftmost bits of the SHA-1 hash value. The result is Hash2.

(3)

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)

4. Set the 8-octet subnetPrefix data value in the encoded
CGAParameters data item 8-bit collision count to zero.

5. Concatenate the given modifier, subnet prefix.

Aura Expires December 13, 2003 [Page 5]

INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003

(5) prefix, collision count and the
encoded public key. Execute the SHA-1 algorithm on the new DER-encoded
CGAParameters data value.
concatenation. Take the 64 leftmost bits of the SHA-1 hash value.
The result is Hash1.

(6)

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

(7) zero.

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

(8)

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

In order to avoid trying

9. Form the same CGA Parameters data structure by concatenating the final
modifier values repeatedly, it value, the subnet prefix, the final collision count
value, and the encoded public key.

The output of the address generation algorithm is
RECOMMENDED to that the a new CGA
address and a CGA Parameters data structure.

The initial modifier value of the modifier 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

Aura Expires January 30, 2004 [Page 7]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

order can be chosen arbitrarily and overflows
can be ignored. to make addresses generated from the same public key unlinkable
to enhance privacy (see Section 7.3). The quality of the random
number generator is does not
important as long as affect the same values are not repeated frequently.
However, if privacy enhancement (see Section 7.3) is required, strength of the
random numbers should be unpredictable binding between
the address and unlinkable. the public key.

For Sec=0, the above algorithm is deterministic and relatively fast.
Nodes that implement CGA generation MAY set always use the security
parameter Sec to always 0. In that case, value Sec=0. If Sec=0, 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
It is intentional 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 current 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.

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.

Aura Expires January 30, 2004 [Page 8]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

5. CGA Verification

CGA verification takes two inputs: as input an IPv6 address and a DER-
encoded CGAParameters CGA Parameters
data item. structure. The CGA Parameters consist of the concatenated
modifier, subnet prefix, collision count and public key. The
verification either succeeds or fails.

Aura Expires December 13, 2003 [Page 6]

INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003

The CGA address MUST be verified with the following steps:

(1)

1. Check that the "g" and "u" bits collision count in the interface identifier
are both zero. If either bit CGA Parameters data
structure is non-zero, the 0, 1 or 2. The CGA verification fails.

(2) Read the security parameter Sec from the three leftmost bits
of the 64-bit interface identifier of fails if the address. (Sec
collision count is
an unsigned 3-bit integer.)

(3) Decode out of the DER-encoded CGAParameters data item. valid range.

2. Check that the subnetPrefix subnet prefix in the CGA Parameters data value structure
is equal to the subnet prefix
(i.e. (i.e., the 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) prefix values differ.

3. Execute the SHA-1 algorithm on the DER-encoded CGAParameters CGA Parameters data value. structure.
Take the 64 leftmost bits of the SHA-1 hash value. The result is
Hash1.

(5)

4. Compare Hash1 with the interface identifier (i.e. (i.e., the rightmost
64 bits) of the address. Differences in the "g"
and "u" three leftmost bits
and in the three leftmost 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.

(6) Set

5. Read the subnetPrefix data value in security parameter Sec from the DER-encoded
CGAParameters data item to 8 three leftmost bits of
the 64-bit interface identifier of the address. (Sec is an
unsigned 3-bit integer.)

6. Concatenate the modifier, 9 zero octets octets, and the
collisionCount data value to 0.

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

(8)

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

If the verification succeeds, the verifier knows that the publicKey
field public key
in the CGAParameters data value CGA Parameters is the authentic public key of the address
owner. The verifier can extract the public key by removing 25 bytes
from the beginning of the CGA Parameters.

Note that the values of bits 6 and 7 (the "u" and "g" bits) of the
interface identifier are ignored during CGA verification. After the
verification succeeds, the verifier SHOULD process all CGA addresses

Aura Expires January 30, 2004 [Page 9]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

the in the same way regardless of the Sec, modifier and collision
count values. In particular, the verifier SHOULD NOT have any
security policy that differentiates between addresses based on the
value of Sec. That way, the address generator is free choose the
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 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) (5)-(7) and these steps MAY can be skipped.

After the

Nodes that implement CGA verification succeeds or fails, the verifier SHOULD
discard be able to process RSA
public keys that have the Sec, modifier OID rsaEncryption and collisionCount values key length between
384 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). 2048 bits. Implementations MAY support longer keys. Future extensions
versions of this specification may define situations where a it is acceptable recommend support for
the verifier to set higher minSec values. longer keys.

Aura Expires January 30, 2004 [Page 10]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

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

This section gives additional guidance on using defines the procedures for generating and verifying CGA
authorization mechanism in these messages.

6.1 Sending SEND Messages

sNodes that use
signatures. In order to sign a message, a node needs the Secure Neighbor Discovery (SEND) protocol and
use CGA addresses MUST use the format of address,
the associated CGA addresses as
described in Section 2, SHOULD generate Parameters data structure, the addresses as described
in Section 4.

The public key used for message, and the address generation MUST have
private cryptographic key that corresponds to the object
identifier sha1WithRSAEncryption [JK03]. The RSA public key MUST be
at least 1024 bits long.

A in the
CGA Parameters. The node that has also needs to have a CGA address MAY use 128-bit type tag for
the message from 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 Message Type name space.

To sign a CGA address message, a node SHOULD do the following:

o Concatenate the 128-bit type tag and the source link-layer address option message. The
concatenation is present the message to be signed in the message.
Note that next step.

o Generate the node MAY use trusted-root authorization mechanism
instead or in addition to RSA signature using the CGA authorization mechanism
authentication. RSASSA-PKCS1-v1_5
[PKCS.1.1993] signature algorithm with the SHA-1 hash algorithm.
The mechanism inputs to be used is determined by the
node's IPSec configuration.

When sending generation operation are the private key and the
concatenation created above.

The SEND protocol specification [I-D.arkko-send-ndopt] defines
several messages that contain a secure NA, NS, RA or RS message, signature in the node MUST
protect Signature Option.
The SEND protocol specification also defines a type tag from the CGA
Message Type name space for each message with an IPSec Authentication Header (AH) type that
uses contains the AH_RSA_Sig transform defined
Signature Option. These type tags are IANA-allocated 128 bit integers
that have been chosen in [AKSZ03]. Within random to prevent accidental type collision
with messages of other protocols that use the same public key but may
or may not use IANA-allocated type tags.

The CGA address, the AH, CGA Parameters data structure, the contents of message, and
the Key Information field signature are represented as ASN.1
DER-encoded data item of sent to 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 verifier. The SEND protocol
specification defines how this data is sent in
[AKSZ03].)

When SEND protocol
messages. Note that the CGA authorization mechanism 128-bit type tag is used not included in a the SEND message,
protocol messages because the
cgaParameters field in SendKeyInformation MUST be present and verifier knows its value MUST be the same CGAParameters data value that was used for
generating implicitly
from the IP source address of ICMP message type field in the SEND message. The signature
in

In order to verify a signature, the AH MUST be verifiable with verifier needs the public key that is sent in CGA address,
the CGAParameters.

6.2 Receiving SEND messages

Received SEND messages MUST be processed as specified in Section
7.1.6 of [AKSZ03]. If associated CGA Parameters data structure, the security association requires message, and the
verification of
signature. The verifier also needs to have the CGA property, 128-bit type tag for
the receiver must message.

To verify the MUST
verify signature, a node SHOULD do the source address of following:

o Verify the packet CGA address as described defined in Section 5. The inputs for to the algorithm
CGA verification are the source CGA address of and the CGA Parameters data
structure.

o Concatenate the packet 128-bit type tag and the contents of message. The
concatenation is the message whose signature is to be verified in

Aura Expires January 30, 2004 [Page 11]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

the next step.

o Verify the RSA signature using the RSASSA-PKCS1-v1_5 [PKCS.1.1993]
algorithm with the SHA-1 hash algorithm. The inputs to the
verification operation are the public key (i.e., the CGAParameters
RSAEncryptionKey structure from the Key
Information field.

If SubjectPublicKeyInfo structure
that is a part of the CGA verification is successful, Parameters data structure), the node goes on to verify
concatenation created above, and the signature in signature.

The verifier accepts the AH signature as defined in [AKSZ03]. On the other hand, authentic only if both the CGA
verification fails, the recipient MUST stop processing
the SEND message and ignore its contents. the signature verification succeed.

Aura Expires January 30, 2004 [Page 12]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

7. Security Considerations

7.1 Security Goals and Limitations

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

It is important to understand that that an 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 CGA Parameters data value, structure, there are Sec 4*(Sec+1)
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. address, and the "u" and
"g" bits can be chosen freely. 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.
(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 An attacker does not both. This
effectively means that secure and insecure benefit from
this because although SEND 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] accept both signed 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, unsigned
messages from every address, they give priority to IP addresses. the information in
the signed messages.

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

Aura Expires January 30, 2004 [Page 13]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

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

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 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, 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. (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 on the assumption
that the computational capacity capacities of the attacker and the address
generator will grow and at the same (potentially exponential) rate. This
is clearly not necessarily true if the addresses are generated on low-end
mobile devices. devices where the main design goals are lower cost and smaller
size rather than increased computing power. But there is no reason
for doing so. The expensive part of the address generation (steps (2)-(3)
(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.

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

Aura Expires January 30, 2004 [Page 14]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

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 Secure Neighbor Discovery and CGA-
based 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 denial-of-service attacks
based on brute-force search become a significant problem. (If CGA address
addresses 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 collision count value is used to modify the input to Hash1 if
there is an address collision. It is important not to allow
collisionCount 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, 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 collision count without repeating the brute-force
search for the modifier value. Thus, the more different values are
allowed for
collisionCount, the collision count, 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]. [RFC3041]. 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].
[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.

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. (e.g., DNS servers, routers, and data
servers) usually do not require pseudonymity, while the nodes that

Aura Expires January 30, 2004 [Page 15]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

have high privacy requirements (e.g. (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 is a unique identifier for others to correlate
its appearances of the local link. node. 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

7.4 Related protocols

While this document.

Acknowledgments

Many document defines CGA addresses only for the purposes of
Secure Neighbor Discovery, other protocols could be defined elsewhere
that use the ideas in this draft were influenced by Michael Roe,
Christian Huitema and Pekka Nikander. Jari Arkko, Pasi Eronen same addresses and
other participants public keys. This raises the
possibility of related-key attacks where a signed message from one
protocol is replayed in another protocol. This means that other
protocols (perhaps designed without an intimate knowledge of SEND)
could endanger the IETF working group made many helpful
comments.

Intellectual Property Statement

Several IPR claims have been security of SEND.

To prevent the related-protocol attacks, a type tag is prepended to
every message before signing it. 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.

Finally, some cautionary notes should be 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 using CGA-based
authentication for other purposes than SEND. First, the other
protocols should use type tags in RFCs all signed messages in the same way
as SEND does. Because of the possibility of related-protocol attacks,
it is advisable 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 use the public key infrastructure certificate only for signing 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) not for
encryption. Second, CGA-based authentication is particularly suitable
for securing neighbor discovery [RFC2461] and distinguished encoding rules (DER), July 2002. Also
appeared duplicate address
detection [RFC2462] 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 and there must also be a
secure mechanism for mapping higher-layer identifiers, such 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. DNS
names, to IP addresses.

Aura Expires December 13, 2003 January 30, 2004 [Page 13]

INTERNET-DRAFT 16]

Internet-Draft Cryptographically Generated Addresses (CGA) June (CGA)August 2003

[NIS95] Secure hash standard. Federal Information Processing
Standards Publication FIPS PUB 180-1, National Institute

8. IANA Considerations

This document defines a new CGA Message Type name space for use as
type tags in messages may be signed using CGA signatures. The values
in this name space are 128-bit integers. Values in this name space
are allocated as First Come First Served [RFC2434]. IANA assigns new
128-bit values directly without a review.

The new values SHOULD be generated with a strong random-number
generator by the requester. Continuous ranges of
Standards at most 256 values
can be allocated provided that the 120 most significant bits of the
values have been generated with a strong random-number generator. It
is not necessary for IANA to verify the randomness of the requested
values. The name space is essentially unlimited and Technology, Gaithersburg, MD USA, April 1995.

Informative any number of
individual values or ranges of at most 256 values can be allocated.

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.

Aura Expires January 30, 2004 [Page 17]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

Normative References

[AAK+02] Jari

[I-D.arkko-send-ndopt]
Arkko, Tuomas Aura, James Kempf, Vesa-Matti
M�ntyl�, Pekka Nikander, J., "SEcure Neighbor Discovery (SEND)",
draft-arkko-send-ndopt-00 (work in progress), June 2003.

[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 Michael Roe. Securing 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.

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.

[PKCS.1.1993]
RSA Laboratories, "RSA Encryption Standard, Version 2.1",
Public-Key Cryptography Standard PKCS 1, June 2002.

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

Aura Expires January 30, 2004 [Page 18]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

Informative References

[AAKMNR02]
Arkko, J., Aura, T., Kempf, J., Mantyla, V., Nikander, P.
and M. Roe, "Securing IPv6 neighbor discovery and router discovery. In Proc. 2002
discovery", ACM Workshop on Wireless Security (WiSe), pages 77-86, (WiSe 2002),
Atlanta, GA USA, USA , September 2002. ACM Press.

[Aura03] Aura, T., "Cryptographically Generated Addresses (CGA)",
6th Information Security Conference (ISC'03), Bristol, UK
, October 2003.

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

[ND01] Thomas Narten

[RFC3041] Narten, T. and Richard Draves. Privacy extensions R. Draves, "Privacy Extensions for
stateless address autoconfiguration
Stateless Address Autoconfiguration in IPv6. IPv6", RFC 3041, IETF Network
Working Group,
January 2001.

[NN98] Thomas

[RFC2461] Narten, Erik T., Nordmark, E. and William Allen Simpson.
Neighbor discovery W. Simpson, "Neighbor
Discovery for IP version Version 6 (IPv6). (IPv6)", RFC 2461, IETF Network
Working Group, December
1998.

[Nik01] Pekka Nikander. A Nikander, P., "A scaleable architecture for IPv6 address
ownership. Internet-draft,
ownership", draft-nikander-addr-ownership-00 (work in
progress), March 2001. Work in Progress.

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

[TN98] Susan Thomson

[RFC2462] Thomson, S. and Thomas Narten. IPv6 stateless address
autoconfiguration. T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, IETF Network Working Group, December 1998.

Aura Expires January 30, 2004 [Page 19]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

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 Expires January 30, 2004 [Page 20]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

Appendix A. Example of CGA Generation

TBW

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

This appendix Generation

We generate a CGA address 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 is Hash2=436b 9a70 dbfd dbf1 926e 6e66 29c0. This does not
begin with 16*Sec=16 zero bits. Thus, we must increment the modifier
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 Expires January 30, 2004 [Page 21]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

Finally, we form the IPv6 address fe80::3c4a:5bf6:ffb4:ca6c. This is
the new CGA address. No address collisions are detected. The CGA
Parameters data structure associated with the address is the same as
the input to Hash1 above.

Aura Expires January 30, 2004 [Page 22]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

Appendix B. Changes since draft-ietf-send-cga-00

1. The verifier MUST now ignore the values of the "u" and "g" bits.
Since no combination of these bits has been allocated for CGAs
only, there is no reason for the verifier to care. The
generation algorithm still says that both bits SHOULD be set
zero.

2. Corrected an error in the bit masks in Section 2 that was left
when Sec was moved to the leftmost bits. Also, the decision to
ignore the values of the "u" and "g" bits makes is possible to
write the CGA definition with two bit masks instead of the
previous three.

3. The CGA parameters (modifier, subnet prefix, collision count and
public key) are now concatenated instead of defining an ASN.1
structure for them. The public key is still in ASN.1 format.

4. PKCS #1 RSA public keys are recommended. The key OID SHOULD be
1.2.840.113549.1.1.1, which is the standard RSA key type.

5. Changed the minimum RSA key length to 384. The reason for the
previous minimum of 1024 bits went away because the CGA
Parameters are a concatenation rather than an ASN.1 structure.
It is ok to let the address owner to choose any key length.
However, it is better to define some minimum because otherwise
implementations might react differently to really short keys.

6. The verifier SHOULD support keys from 384 to 2048 bits. We need
to say something about the upper bound of the key length because
otherwise every implementation will have a different limit.

7. Removed references to IPSec. Referencing draft-arkko-send-ndopt
until the next working-group draft is available.

8. Rewrote section 6. A type tag is prepended to messages before
signing to prevent related-protocol attacks.

9. Added IANA considerations section. A new name space called CGA
Message Type is intended only created for the readers who reviewed a
preliminary version of type tags. No values are
allocated in this draft titled draft-aura-cga-pre01.

o document. The number of zero bits in hash 2 is 16*Sec (was 12*Sec),
length SEND protocol specification will
allocate one value for each of Hash2 is 112 bits (was 84 bits), and the length five signed message types
SEND.

10. Added an example of
modifier 16 octets (was 12 octets). Makes coding easier and
extends the maximal hash length. key generation (Appendix A). The example
still requires independent verification.

11. Many editorial changes throughout.

Aura Expires December 13, 2003 January 30, 2004 [Page 14]

INTERNET-DRAFT 23]

Internet-Draft Cryptographically Generated Addresses (CGA) June (CGA)August 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

Appendix C. Acknowledgments

The author gratefully acknowledges the order contributions of the publicKey Jari Arkko,
Francis DuPont, Pasi Eronen, Christian Huitema, Pekka Nikander,
Michael Roe, Dave Thaler, and auxParameters fields several other participants 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 IETF
working group.

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

Phone: +44 1223 479708
Email: tuomaura@microsoft.com Expires January 30, 2004 [Page 24]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

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

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

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

Aura Expires January 30, 2004 [Page 25]

Internet-Draft Cryptographically Generated Addresses (CGA)August 2003

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Aura Expires December 13, 2003 January 30, 2004 [Page 16] 26]

----