< draft-ietf-send-cga-05.txt   draft-ietf-send-cga-06.txt >
Securing Neighbor Discovery T. Aura Securing Neighbor Discovery T. Aura
Internet-Draft Microsoft Research Internet-Draft Microsoft Research
Expires: August 6, 2004 February 6, 2004 Expires: October 15, 2004 April 16, 2004
Cryptographically Generated Addresses (CGA) Cryptographically Generated Addresses (CGA)
draft-ietf-send-cga-05 draft-ietf-send-cga-06
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 30 skipping to change at page 1, line 30
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 6, 2004. This Internet-Draft will expire on October 15, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document describes a method for binding a public signature key This document describes a method for binding a public signature key
to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol.
Cryptographically Generated Addresses (CGA) are IPv6 addresses where Cryptographically Generated Addresses (CGA) are IPv6 addresses where
skipping to change at page 2, line 8 skipping to change at page 2, line 8
re-computing the hash value and by comparing the hash with the re-computing the hash value and by comparing the hash with the
interface identifier. Messages sent from an IPv6 address can be interface identifier. Messages sent from an IPv6 address can be
protected by attaching the public key and auxiliary parameters and by protected by attaching the public key and auxiliary parameters and by
signing the message with the corresponding private key. The signing the message with the corresponding private key. The
protection works without a certification authority or other security protection works without a certification authority or other security
infrastructure. infrastructure.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. CGA Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. CGA Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. CGA Parameters and Hash Values . . . . . . . . . . . . . . . . 7 3. CGA Parameters and Hash Values . . . . . . . . . . . . . . . . 5
4. CGA Generation . . . . . . . . . . . . . . . . . . . . . . . . 8 4. CGA Generation . . . . . . . . . . . . . . . . . . . . . . . . 7
5. CGA Verification . . . . . . . . . . . . . . . . . . . . . . . 10 5. CGA Verification . . . . . . . . . . . . . . . . . . . . . . . 9
6. CGA Signatures . . . . . . . . . . . . . . . . . . . . . . . . 12 6. CGA Signatures . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7.1 Security Goals and Limitations . . . . . . . . . . . . . . . . 14 7.1 Security Goals and Limitations . . . . . . . . . . . . . . 12
7.2 Hash extension . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2 Hash extension . . . . . . . . . . . . . . . . . . . . . . 13
7.3 Privacy Considerations . . . . . . . . . . . . . . . . . . . . 16 7.3 Privacy Considerations . . . . . . . . . . . . . . . . . . 15
7.4 Related protocols . . . . . . . . . . . . . . . . . . . . . . 17 7.4 Related protocols . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
Normative References . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Informative References . . . . . . . . . . . . . . . . . . . . 20 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 9.2 Informative References . . . . . . . . . . . . . . . . . . . 18
A. Example of CGA Generation . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 A. Example of CGA Generation . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 25 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 21
1. Introduction 1. Introduction
This document specifies a method for securely associating a This document specifies a method for securely associating a
cryptographic public key with an IPv6 address in the Secure Neighbor cryptographic public key with an IPv6 address in the Secure Neighbor
Discovery (SEND) protocol [I-D.ietf-send-ndopt]. The basic idea is to Discovery (SEND) protocol [I-D.ietf-send-ndopt]. The basic idea is to
generate the interface identifier (i.e., the rightmost 64 bits) of generate the interface identifier (i.e., the rightmost 64 bits) of
the IPv6 address by computing a cryptographic hash of the public key. the IPv6 address by computing a cryptographic hash of the public key.
The resulting IPv6 address is called a cryptographically generated The resulting IPv6 address is called a cryptographically generated
address (CGA). The corresponding private key can then be used to sign address (CGA). The corresponding private key can then be used to sign
messages sent from the address. messages sent from the address.
skipping to change at page 3, line 46 skipping to change at page 3, line 46
certified, an attacker can create a new CGA from any subnet prefix certified, an attacker can create a new CGA from any subnet prefix
and its own (or anyone else's) public key. What the attacker cannot and its own (or anyone else's) public key. What the attacker cannot
do is to take a CGA created by someone else and send signed messages do is to take a CGA created by someone else and send signed messages
that appear to come from the owner of that address. that appear to come from the owner of that address.
The address format and the CGA parameter format are defined in The address format and the CGA parameter format are defined in
Sections 2 and 3. Detailed algorithms for generating addresses and Sections 2 and 3. Detailed algorithms for generating addresses and
for verifying them are given in Sections 4 and 5, respectively. for verifying them are given in Sections 4 and 5, respectively.
Section 6 defines the procedures for generating and verifying CGA Section 6 defines the procedures for generating and verifying CGA
signatures. The security considerations in Section 7 include signatures. The security considerations in Section 7 include
limitations of CGA-based authentication, the reasoning behind the limitations of CGA-based security, the reasoning behind the hash
hash extension technique that enables effective hash lengths above extension technique that enables effective hash lengths above the
the 64-bit limit of the interface identifier, the implications of 64-bit limit of the interface identifier, the implications of CGAs on
CGAs on privacy, and protection against related-protocol attacks. privacy, and protection against related-protocol attacks.
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to
be interpreted as described in [RFC2119]. be interpreted as described in [RFC2119].
2. CGA Format 2. CGA Format
When talking about addresses, this document refers to IPv6 addresses When talking about addresses, this document refers to IPv6 addresses
where the leftmost 64 bits of a 128-bit address form the subnet 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 prefix and the rightmost 64 bits of the address form the interface
identifier [RFC3513]. We number the bits of the interface identifier identifier [RFC3513]. We number the bits of the interface identifier
starting from bit 0 on the left. starting from bit 0 on the left.
A cryptographically generated address (CGA) has a security parameter A cryptographically generated address (CGA) has a security parameter
(Sec), which determines its strength against brute-force attacks. The (Sec), which determines its strength against brute-force attacks. The
security parameter is a 3-bit unsigned integer and it is encoded in security parameter is a 3-bit unsigned integer and it is encoded in
skipping to change at page 7, line 5 skipping to change at page 5, line 12
0xffffffffffffffffffff00000000 if Sec=5, 0xffffffffffffffffffff00000000 if Sec=5,
0xffffffffffffffffffffffff0000 if Sec=6, and 0xffffffffffffffffffffffff0000 if Sec=6, and
0xffffffffffffffffffffffffffff if Sec=7 0xffffffffffffffffffffffffffff if Sec=7
A cryptographically generated address is an IPv6 address for which A cryptographically generated address is an IPv6 address for which
the following two equations hold: the following two equations hold:
Hash1 & Mask1 == interface identifier & Mask1 Hash1 & Mask1 == interface identifier & Mask1
Hash2 & Mask2 == 0x0000000000000000000000000000 Hash2 & Mask2 == 0x0000000000000000000000000000
3. CGA Parameters and Hash Values 3. CGA Parameters and Hash Values
Each CGA is associated with a public key and auxiliary parameters. Each CGA is associated with a CGA Parameters data structure, which
The public key MUST be formatted as a DER-encoded [ITU.X690.2002] has the following format:
ASN.1 structure of the type SubjectPublicKeyInfo defined in the
Internet X.509 certificate profile [RFC3280]. For SEND, 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 field SHOULD be formatted as an ASN.1 data structure of the type
RSAEncryptionKey defined in [PKCS.1.2002]. The RSA key length SHOULD
be at least 384 bits. Other public key types or format SHOULD NOT be
used for SEND to avoid incompatibilities [I-D.ietf-send-ndopt].
The auxiliary parameters are the following three unsigned integers: 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Modifier (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subnet Prefix (8 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Collision Count| |
+-+-+-+-+-+-+-+-+ |
| |
~ Public Key (variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extension Fields (optional, variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o a 128-bit modifier, which can be any value, Modifier
o a 64-bit subnet prefix, which is equal to the subnet prefix of the This field contains a 128-bit unsigned integer, which can be any
CGA, and value. The modifier is used during CGA generation to implement the
hash extension and to enhance privacy by adding randomness to the
address.
o an 8-bit collision count, which can have values 0, 1 and 2. Subnet Prefix
We use the name "CGA Parameters" for the data structure that is the This field contains the 64-bit subnet prefix of the CGA.
concatenation (from left to right) of the 16-octet modifier, the
8-octet subnet prefix, the 1-octet collision count, and the Collision Count
variable-length encoded public key (i.e., the SubjectPublicKeyInfo
structure). This is an 8-bit unsigned integer, which MUST be 0, 1 or 2. The
collision count is incremented during CGA generation to recover
from an address collision detected by duplicate address detection.
Public Key
This is a variable length field containing the public key of the
address owner. The public key MUST be formatted as a DER-encoded
[ITU.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo
defined in the Internet X.509 certificate profile [RFC3280]. SEND
SHOULD use an RSA public/private key pair. When RSA is used, the
algorithm identifier MUST be rsaEncryption, which is
1.2.840.113549.1.1.1, and the RSA public key MUST be formatted
using the RSAPublicKey type as specified in Section 2.3.1 of RFC
3279 [RFC3279]. The RSA key length SHOULD be at least 384 bits.
Other public key types are undesirable in SEND since they may
result in incompatibilities between implementations. The length of
this field is determined by the ASN.1 encoding.
Extension Fields
This is an optional variable-length field, which is not used in
the current specification. Future versions of this specification
may use this field for additional data items that need to be
included in the CGA Parameters data structure. IETF standards
action is required to specify the use of the extension fields.
Implementations MUST ignore the value of any unrecognized
extension fields.
The two hash values MUST be computed as follows. The SHA-1 hash The two hash values MUST be computed as follows. The SHA-1 hash
algorithm [FIPS.180-1.1995] is applied to the public key and algorithm [FIPS.180-1.1995] is applied to the CGA Parameters. When
auxiliary parameters. When computing Hash1, the input to the SHA-1 computing Hash1, the input to the SHA-1 algorithm is the CGA
algorithm is the CGA Parameters data structure. The 64-bit Hash1 is Parameters data structure. The 64-bit Hash1 is obtained by taking the
obtained by taking the leftmost 64 bits of the 160-bit SHA-1 hash leftmost 64 bits of the 160-bit SHA-1 hash value. When computing
value. When computing Hash2, the input is the same CGA Parameters Hash2, the input is the same CGA Parameters data structure except
data structure except that the subnet prefix and collision count are that the subnet prefix and collision count are set to zero. The
set to zero. The 112-bit Hash2 is obtained by taking the leftmost 112 112-bit Hash2 is obtained by taking the leftmost 112 bits of the
bits of the 160-bit SHA-1 hash value. 160-bit SHA-1 hash value. Note that the hash values are computed over
the entire CGA Parameters data structure, including any unrecognized
extension fields.
4. CGA Generation 4. CGA Generation
The process of generating a new CGA takes three input values: a The process of generating a new CGA takes three input values: a
64-bit subnet prefix, the public key of the address owner as a 64-bit subnet prefix, the public key of the address owner as a
DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo, and the DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo, and the
security parameter Sec, which is an unsigned 3-bit integer. The cost security parameter Sec, which is an unsigned 3-bit integer. The cost
of generating a new CGA depends exponentially on the security of generating a new CGA depends exponentially on the security
parameter Sec, which can have values from 0 to 7. parameter Sec, which can have values from 0 to 7.
A CGA and associated parameters SHOULD be generated as follows: A CGA and associated parameters SHOULD be generated as follows:
skipping to change at page 8, line 43 skipping to change at page 7, line 43
6. Form an interface identifier from Hash1 by writing the value of 6. Form an interface identifier from Hash1 by writing the value of
Sec into the three leftmost bits and by setting bits 6 and 7 Sec into the three leftmost bits and by setting bits 6 and 7
(i.e., the "u" and "g" bits) both to zero. (i.e., the "u" and "g" bits) both to zero.
7. Concatenate the 64-bit subnet prefix and the 64-bit interface 7. Concatenate the 64-bit subnet prefix and the 64-bit interface
identifier to form a 128-bit IPv6 address with the subnet prefix identifier to form a 128-bit IPv6 address with the subnet prefix
to the left and interface identifier to the right as in a to the left and interface identifier to the right as in a
standard IPv6 address [RFC3513]. standard IPv6 address [RFC3513].
8. Perform address collision detection if required, as per 8. Perform duplicate address detection if required, as per
[I-D.ietf-send-ndopt]. If an address collision is detected, [I-D.ietf-send-ndopt]. If an address collision is detected,
increment the collision count by one and go back to step (5). increment the collision count by one and go back to step (5).
However, after three collisions, stop and report the error. However, after three collisions, stop and report the error.
9. Form the CGA Parameters data structure by concatenating from left 9. Form the CGA Parameters data structure by concatenating from left
to right the final modifier value, the subnet prefix, the final to right the final modifier value, the subnet prefix, the final
collision count value, and the encoded public key. collision count value, and the encoded public key.
The output of the address generation algorithm is a new CGA and a CGA The output of the address generation algorithm is a new CGA and a CGA
Parameters data structure. Parameters data structure.
The initial value of the modifier in step (1) SHOULD be chosen The initial value of the modifier in step (1) SHOULD be chosen
randomly in order to make addresses generated from the same public randomly in order to make addresses generated from the same public
key unlinkable, which enhances privacy (see Section 7.3). The quality key unlinkable, which enhances privacy (see Section 7.3). The quality
of the random number generator does not affect the strength of the of the random number generator does not affect the strength of the
binding between the address and the public key. binding between the address and the public key. Implementations that
have no strong random numbers available MAY use a non-cryptographic
pseudo-random number generator that is initialized with the current
time of day.
For Sec=0, the above algorithm is deterministic and relatively fast. For Sec=0, the above algorithm is deterministic and relatively fast.
Nodes that implement CGA generation MAY always use the security Nodes that implement CGA generation MAY always use the security
parameter value Sec=0. If Sec=0, steps (2)-(3) of the generation parameter value Sec=0. If Sec=0, steps (2)-(3) of the generation
algorithm can be skipped. algorithm can be skipped.
For Sec values greater than 0, the above algorithm is not guaranteed For Sec values greater than 0, the above algorithm is not guaranteed
to terminate after a certain number of iterations. The brute-force to terminate after a certain number of iterations. The brute-force
search in steps (2)-(3) takes O(2^(16*Sec)) iterations to complete. search in steps (2)-(3) takes O(2^(16*Sec)) iterations to complete.
It is intentional that generating CGAs with high Sec values is It is intentional that generating CGAs with high Sec values is
skipping to change at page 10, line 5 skipping to change at page 8, line 49
SHOULD be started from step (4). This optimization avoids repeating SHOULD be started from step (4). This optimization avoids repeating
the expensive search for an acceptable modifier value but may, in the expensive search for an acceptable modifier value but may, in
some situations, make it easier for an observer to link two addresses some situations, make it easier for an observer to link two addresses
to each other. to each other.
Note that this document does not specify whether duplicate address Note that this document does not specify whether duplicate address
detection should be performed and how the detection is done. Step (8) detection should be performed and how the detection is done. Step (8)
only defines what to do if some form of duplicate address detection only defines what to do if some form of duplicate address detection
is performed and an address collision is detected. is performed and an address collision is detected.
5. CGA Verification Future versions of this specification may specify additional inputs
to the CGA generation algorithm, which are concatenated as extension
fields to the end of the CGA Parameters data structure. This document
does not specify how such data fields are handled during CGA
generation.
5. CGA Verification
CGA verification takes as input an IPv6 address and a CGA Parameters CGA verification takes as input an IPv6 address and a CGA Parameters
data structure. The CGA Parameters consist of the concatenated data structure. The CGA Parameters consist of the concatenated
modifier, subnet prefix, collision count, and public key. The modifier, subnet prefix, collision count, public key, and optional
verification either succeeds or fails. extension fields. The verification either succeeds or fails.
The CGA MUST be verified with the following steps: The CGA MUST be verified with the following steps:
1. Check that the collision count in the CGA Parameters data 1. Check that the collision count in the CGA Parameters data
structure is 0, 1 or 2. The CGA verification fails if the structure is 0, 1 or 2. The CGA verification fails if the
collision count is out of the valid range. collision count is out of the valid range.
2. Check that the subnet prefix in the CGA Parameters data structure 2. Check that the subnet prefix in the CGA Parameters data structure
is equal to the subnet prefix (i.e., the leftmost 64 bits) of the is equal to the subnet prefix (i.e., the leftmost 64 bits) of the
address. The CGA verification fails if the prefix values differ. address. The CGA verification fails if the prefix values differ.
skipping to change at page 10, line 37 skipping to change at page 9, line 39
64 bits) of the address. Differences in the three leftmost bits 64 bits) of the address. Differences in the three leftmost bits
and in bits 6 and 7 (i.e., the "u" and "g" bits) are ignored. If and in bits 6 and 7 (i.e., the "u" and "g" bits) are ignored. If
the 64-bit values differ (other than in the five ignored bits), the 64-bit values differ (other than in the five ignored bits),
the CGA verification fails. the CGA verification fails.
5. Read the security parameter Sec from the three leftmost bits of 5. Read the security parameter Sec from the three leftmost bits of
the 64-bit interface identifier of the address. (Sec is an the 64-bit interface identifier of the address. (Sec is an
unsigned 3-bit integer.) unsigned 3-bit integer.)
6. Concatenate from left to right the modifier, 9 zero octets, and 6. Concatenate from left to right the modifier, 9 zero octets, and
the public key. Execute the SHA-1 algorithm on the concatenation. the public key, and any extension fields that follow the public
Take the 112 leftmost bits of the SHA-1 hash value. The result is key in the CGA Parameters data structure. Execute the SHA-1
Hash2. algorithm on the concatenation. Take the 112 leftmost bits of the
SHA-1 hash value. The result is Hash2.
7. Compare the 16*Sec leftmost bits of Hash2 with zero. If any one 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 of them is non-zero, the CGA verification fails. Otherwise, the
verification succeeds. (If Sec=0, the CGA verification never verification succeeds. (If Sec=0, the CGA verification never
fails at this step.) fails at this step.)
If the verification fails at any step, the execution of the algorithm If the verification fails at any step, the execution of the algorithm
MUST be stopped immediately. On the other hand, if the verification MUST be stopped immediately. On the other hand, if the verification
succeeds, the verifier knows that the public key in the CGA succeeds, the verifier knows that the public key in the CGA
Parameters is the authentic public key of the address owner. The Parameters is the authentic public key of the address owner. The
verifier can extract the public key by removing 25 bytes from the verifier can extract the public key by removing 25 octets from the
beginning of the CGA Parameters and by decoding the following beginning of the CGA Parameters and by decoding the following
SubjectPublicKeyInfo data structure. Future versions of this SubjectPublicKeyInfo data structure.
specification may add new fields to the end of the CGA Parameters and
the verifier SHOULD ignore any unrecognized data that follows the
encoded public key.
Note that the values of bits 6 and 7 (the "u" and "g" bits) of the Note that the values of bits 6 and 7 (the "u" and "g" bits) of the
interface identifier are ignored during CGA verification. In the SEND interface identifier are ignored during CGA verification. In the SEND
protocol, after the verification succeeds, the verifier SHOULD protocol, after the verification succeeds, the verifier SHOULD
process all CGAs in the same way regardless of the Sec, modifier and process all CGAs in the same way regardless of the Sec, modifier and
collision count values. In particular, the verifier in the SEND collision count values. In particular, the verifier in the SEND
protocol SHOULD NOT have any security policy that differentiates protocol SHOULD NOT have any security policy that differentiates
between addresses based on the value of Sec. That way, the address between addresses based on the value of Sec. That way, the address
generator is free choose any value of Sec. generator is free choose any value of Sec.
All nodes that implement CGA verification MUST be able to process all 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 security parameter values Sec = 0, 1, 2, 3, 4, 5, 6, 7. The
verification procedure is relatively fast and always requires at most verification procedure is relatively fast and always requires at most
two computations of the SHA-1 hash function. If Sec=0, the two computations of the SHA-1 hash function. If Sec=0, the
verification never fails in steps (6)-(7) and these steps can be verification never fails in steps (6)-(7) and these steps can be
skipped. skipped.
Nodes that implement CGA verification for SEND SHOULD be able to Nodes that implement CGA verification for SEND SHOULD be able to
process RSA public keys that have the OID rsaEncryption and key process RSA public keys that have the algorithm identifier
length between 384 and 2048 bits. Implementations MAY support longer rsaEncryption and key length between 384 and 2048 bits.
keys. Future versions of this specification may recommend support for Implementations MAY support longer keys. Future versions of this
longer keys. specification may recommend support for longer keys.
6. CGA Signatures Implementations of CGA verification MUST ignore the value of any
unrecognized extension fields that follow the public key in the CGA
Parameters data structure. However, implementations MUST include any
such unrecognized data in the hash input when computing Hash1 in step
(3) and Hash2 in step (6) of the CGA verification algorithm. This is
important to ensure upward compatibility with future extensions.
6. CGA Signatures
This section defines the procedures for generating and verifying CGA This section defines the procedures for generating and verifying CGA
signatures. In order to sign a message, a node needs the CGA, the signatures. In order to sign a message, a node needs the CGA, the
associated CGA Parameters data structure, the message, and the associated CGA Parameters data structure, the message, and the
private cryptographic key that corresponds to the public key in the private cryptographic key that corresponds to the public key in the
CGA Parameters. The node also needs to have a 128-bit type tag for CGA Parameters. The node also needs to have a 128-bit type tag for
the message from the CGA Message Type name space. the message from the CGA Message Type name space.
To sign a message, a node SHOULD do the following: To sign a message, a node SHOULD do the following:
o Concatenate the 128-bit type tag (in network byte order) and the o Concatenate the 128-bit type tag (in network byte order) and the
message with the type tag to the left and the message to the message with the type tag to the left and the message to the
right. The concatenation is the message to be signed in the next right. The concatenation is the message to be signed in the next
step. step.
o Generate the RSA signature using the RSASSA-PKCS1-v1_5 o Generate the RSA signature using the RSASSA-PKCS1-v1_5 [RFC3447]
[PKCS.1.2002] signature algorithm with the SHA-1 hash algorithm. signature algorithm with the SHA-1 hash algorithm. The inputs to
The inputs to the generation operation are the private key and the the generation operation are the private key and the concatenation
concatenation created above. created above.
The SEND protocol specification [I-D.ietf-send-ndopt] defines several The SEND protocol specification [I-D.ietf-send-ndopt] defines several
messages that contain a signature in the Signature Option. The SEND messages that contain a signature in the Signature Option. The SEND
protocol specification also defines a type tag from the CGA Message protocol specification also defines a type tag from the CGA Message
Type name space. The same type tag is used for all the SEND messages Type name space. The same type tag is used for all the SEND messages
that have the Signature Option. This type tag is an IANA-allocated that have the Signature Option. This type tag is an IANA-allocated
128 bit integer that has been chosen at random to prevent accidental 128 bit integer that has been chosen at random to prevent accidental
type collision with messages of other protocols that use the same type collision with messages of other protocols that use the same
public key but may or may not use IANA-allocated type tags. public key but may or may not use IANA-allocated type tags.
The CGA, the CGA Parameters data structure, the message, and the The CGA, the CGA Parameters data structure, the message, and the
signature are sent to the verifier. The SEND protocol specification signature are sent to the verifier. The SEND protocol specification
defines how this data is sent in SEND protocol messages. Note that defines how these data items are sent in SEND protocol messages. Note
the 128-bit type tag is not included in the SEND protocol messages that the 128-bit type tag is not included in the SEND protocol
because the verifier knows its value implicitly from the ICMP message messages because the verifier knows its value implicitly from the
type field in the SEND message. See the SEND specification ICMP message type field in the SEND message. See the SEND
[I-D.ietf-send-ndopt] for precise information about how SEND handles specification [I-D.ietf-send-ndopt] for precise information about how
the type tag. SEND handles the type tag.
In order to verify a signature, the verifier needs the CGA, the In order to verify a signature, the verifier needs the CGA, the
associated CGA Parameters data structure, the message, and the associated CGA Parameters data structure, the message, and the
signature. The verifier also needs to have the 128-bit type tag for signature. The verifier also needs to have the 128-bit type tag for
the message. the message.
To verify the signature, a node SHOULD do the following: To verify the signature, a node SHOULD do the following:
o Verify the CGA as defined in Section 5. The inputs to the CGA o Verify the CGA as defined in Section 5. The inputs to the CGA
verification are the CGA and the CGA Parameters data structure. verification are the CGA and the CGA Parameters data structure.
o Concatenate the 128-bit type tag and the message with the type tag o Concatenate the 128-bit type tag and the message with the type tag
to the left and the message to the right. The concatenation is the to the left and the message to the right. The concatenation is the
message whose signature is to be verified in the next step. message whose signature is to be verified in the next step.
o Verify the RSA signature using the RSASSA-PKCS1-v1_5 [PKCS.1.2002] o Verify the RSA signature using the RSASSA-PKCS1-v1_5 [RFC3447]
algorithm with the SHA-1 hash algorithm. The inputs to the algorithm with the SHA-1 hash algorithm. The inputs to the
verification operation are the public key (i.e., the verification operation are the public key (i.e., the RSAPublicKey
RSAEncryptionKey structure from the SubjectPublicKeyInfo structure structure from the SubjectPublicKeyInfo structure that is a part
that is a part of the CGA Parameters data structure), the of the CGA Parameters data structure), the concatenation created
concatenation created above, and the signature. above, and the signature.
The verifier MUST accept the signature as authentic only if both the The verifier MUST accept the signature as authentic only if both the
CGA verification and the signature verification succeed. CGA verification and the signature verification succeed.
7. Security Considerations 7. Security Considerations
7.1 Security Goals and Limitations 7.1 Security Goals and Limitations
The purpose of CGAs is to prevent stealing and spoofing of existing The purpose of CGAs is to prevent stealing and spoofing of existing
IPv6 addresses. The public key of the address owner is bound IPv6 addresses. The public key of the address owner is bound
cryptographically to the address. The address owner can use the cryptographically to the address. The address owner can use the
corresponding private key to assert its ownership of the address and corresponding private key to assert its ownership of the address and
to sign SEND messages sent from the address. to sign SEND messages sent from the address.
It is important to understand that an attacker can create a new It is important to understand that an attacker can create a new
address from an arbitrary subnet prefix and its own (or someone address from an arbitrary subnet prefix and its own (or someone
else's) public key because CGAs are not certified. What the attacker else's) public key because CGAs are not certified. What the attacker
skipping to change at page 14, line 38 skipping to change at page 12, line 38
or implementation implications. or implementation implications.
Another limitation of CGAs is that there is no mechanism for proving Another limitation of CGAs is that there is no mechanism for proving
that an address is not a CGA. Thus, an attacker could take someone that an address is not a CGA. Thus, an attacker could take someone
else's CGA and present it as a non-cryptographically-generated else's CGA and present it as a non-cryptographically-generated
address (e.g., as an RFC-3041 address [RFC3041]). An attacker does address (e.g., as an RFC-3041 address [RFC3041]). An attacker does
not benefit from this because although SEND nodes accept both signed not benefit from this because although SEND nodes accept both signed
and unsigned messages from every address, they give priority to the and unsigned messages from every address, they give priority to the
information in the signed messages. information in the signed messages.
7.2 Hash extension The minimum RSA key length required for SEND is only 384 bits. So
short keys are vulnerable to integer-factoring attacks and cannot be
used for strong authentication or secrecy. On the other hand, the
cost of factoring 384-bit keys is currently high enough to prevent
most denial-of-service attacks. Implementations that initially use
short RSA keys SHOULD be prepared switch to longer keys when
denial-of-service attacks arising from integer factoring become a
problem.
The impact of a key compromise on CGAs depends on the application for
which they are used. In SEND, it is not a major concern. If the
private signature key is compromised because the SEND node itself has
been compromised, the attacker does not need to spoof SEND messages
from the node. When it is discovered that a node has been
compromised, a new signature key and a new CGA SHOULD be generated.
On the other hand, if the RSA key is compromised because
integer-factoring attacks for the chosen key length have become
practical, the key needs to be replaced with a longer one, as
explained above. In either case, the address change effectively
revokes the old public key. It is not necessary to have any
additional key revocation mechanism or to limit the lifetimes of the
signature keys.
7.2 Hash extension
As computers become faster, the 64 bits of the interface identifier As computers become faster, the 64 bits of the interface identifier
will not be sufficient to prevent attackers from searching for hash will not be sufficient to prevent attackers from searching for hash
collisions. It helps somewhat that we include the subnet prefix of collisions. It helps somewhat that we include the subnet prefix of
the address in the hash input. This prevents the attacker from using the address in the hash input. This prevents the attacker from using
a single pre-computed database to attack addresses with different a single pre-computed database to attack addresses with different
subnet prefixes. The attacker needs to create a separate database for subnet prefixes. The attacker needs to create a separate database for
each subnet prefix. Link-local addresses are, however, left each subnet prefix. Link-local addresses are, however, left
vulnerable because the same prefix is used by all IPv6 nodes. vulnerable because the same prefix is used by all IPv6 nodes.
skipping to change at page 16, line 8 skipping to change at page 14, line 31
not to include the subnet prefix in the input of Hash2. The result is 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 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 hashes. On the other hand, our scheme is at least as strong as using
the hash extension technique without including the subnet prefix in the hash extension technique without including the subnet prefix in
either hash. It is also at least as strong as not using the hash 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 extension but including the subnet prefix. This trade-off was made
because mobile nodes frequently move to insecure networks where they because mobile nodes frequently move to insecure networks where they
are at the risk of denial-of-service (DoS) attacks, for example, are at the risk of denial-of-service (DoS) attacks, for example,
during the duplicate address detection procedure. during the duplicate address detection procedure.
In most networks, the goal of Secure Neighbor Discovery and CGA-based In most networks, the goal of Secure Neighbor Discovery and CGA
authentication is to prevent denial-of-service attacks. Therefore, it signatures is to prevent denial-of-service attacks. Therefore, it is
is usually sensible to start by using a low Sec value and to replace usually sensible to start by using a low Sec value and to replace
addresses with stronger ones only when denial-of-service attacks addresses with stronger ones only when denial-of-service attacks
based on brute-force search become a significant problem. (If CGAs based on brute-force search become a significant problem. If CGAs
were used as a part of a strong authentication or secrecy mechanisms, were used as a part of a strong authentication or secrecy mechanism,
it would be necessary to start with higher Sec values.) it might be necessary to start with higher Sec values.
The collision count value is used to modify the input to Hash1 if The collision count value is used to modify the input to Hash1 if
there is an address collision. It is important not to allow collision there is an address collision. It is important not to allow collision
count values higher than 2. First, it is extremely unlikely that count values higher than 2. First, it is extremely unlikely that
three collisions would occur and the reason is certain to be either a three collisions would occur and the reason is certain to be either a
configuration or implementation error or a denial-of-service attack. configuration or implementation error or a denial-of-service attack.
(When the SEND protocol is used, the deliberate collisions caused by (When the SEND protocol is used, deliberate collisions caused by a
a DoS attacker are detected and ignored.) Second, an attacker who is DoS attacker are detected and ignored.) Second, an attacker who is
doing a brute-force search to match a given CGA can try all different doing a brute-force search to match a given CGA can try all different
values of collision count without repeating the brute-force search values of collision count without repeating the brute-force search
for the modifier value. Thus, if higher values are allowed for the for the modifier value. Thus, if higher values are allowed for the
collision count, the hash extension technique becomes less effective collision count, the hash extension technique becomes less effective
in preventing brute force attacks. in preventing brute force attacks.
7.3 Privacy Considerations 7.3 Privacy Considerations
CGAs can give the same level pseudonymity as the IPv6 address privacy CGAs can give the same level pseudonymity as the IPv6 address privacy
extensions defined in RFC 3041 [RFC3041]. An IP host can generate extensions defined in RFC 3041 [RFC3041]. An IP host can generate
multiple pseudorandom CGAs by executing the CGA generation algorithm multiple pseudorandom CGAs by executing the CGA generation algorithm
of Section 4 multiple times and using a different random or of Section 4 multiple times and using a different random or
pseudorandom initial value for the modifier every time. The host pseudorandom initial value for the modifier every time. The host
should change its address periodically as in [RFC3041]. When privacy should change its address periodically as in [RFC3041]. When privacy
protection is needed, the (pseudo)random number generator used in protection is needed, the (pseudo)random number generator used in
address generation SHOULD be strong enough to produce unpredictable address generation SHOULD be strong enough to produce unpredictable
and unlinkable values. and unlinkable values. Advice on random number generation can be
found in [RFC1750].
There are two apparent limitations to this privacy protection. There are two apparent limitations to this privacy protection.
However, as we will explain below, neither limitation is very However, as will be explained below, neither limitation is very
serious. serious.
First, the high cost of address generation may prevent hosts that use First, the high cost of address generation may prevent hosts that use
a high Sec value from changing their address frequently. This problem a high Sec value from changing their address frequently. This problem
is mitigated by the fact that the expensive part of the address is mitigated by the fact that the expensive part of the address
generation may be done in advance or offline, as explained in the generation may be done in advance or offline, as explained in the
previous section. It should also be noted that the nodes that benefit previous section. It should also be noted that the nodes that benefit
most from high Sec values (e.g., DNS servers, routers, and data most from high Sec values (e.g., DNS servers, routers, and data
servers) usually do not require pseudonymity, while the nodes that servers) usually do not require pseudonymity, while the nodes that
have high privacy requirements (e.g., client PCs and mobile hosts) have high privacy requirements (e.g., client PCs and mobile hosts)
are unlikely targets for expensive brute-force DoS attacks and can do are unlikely targets for expensive brute-force DoS attacks and can do
with lower Sec values. with lower Sec values.
Second, the public key of the address owner is revealed in the Second, the public key of the address owner is revealed in the signed
authenticated SEND messages. This means that if the address owner SEND messages. This means that if the address owner wants to be
wants to be pseudonymous towards the nodes in the local links that it pseudonymous towards the nodes in the local links that it accesses,
accesses, it should not only generate a new address but also a new it should not only generate a new address but also a new public key.
public key. With typical local-link technologies, however, a node's With typical local-link technologies, however, a node's link-layer
link-layer address is a unique identifier for the node. As long as address is a unique identifier for the node. As long as the node
the node keeps using the same link-layer address, it makes little keeps using the same link-layer address, it makes little sense to
sense to ever change the public key for privacy reasons. ever change the public key for privacy reasons.
7.4 Related protocols 7.4 Related protocols
While this document defines CGAs only for the purposes of Secure While this document defines CGAs only for the purposes of Secure
Neighbor Discovery, other protocols could be defined elsewhere that Neighbor Discovery, other protocols could be defined elsewhere that
use the same addresses and public keys. This raises the possibility use the same addresses and public keys. This raises the possibility
of related-key attacks where a signed message from one protocol is of related-protocol attacks where a signed message from one protocol
replayed in another protocol. This means that other protocols is replayed in another protocol. This means that other protocols
(perhaps designed without an intimate knowledge of SEND) could (perhaps designed without an intimate knowledge of SEND) could
endanger the security of SEND. What makes this threat even more endanger the security of SEND. What makes this threat even more
significant is that the attacker could take someone else's public key significant is that the attacker could take someone else's public key
and create a CGA from it, and then replay signed messages from a and create a CGA from it, and then replay signed messages from a
protocol that has nothing to do with CGAs or IP addresses. protocol that has nothing to do with CGAs or IP addresses.
To prevent the related-protocol attacks, a type tag is prepended to To prevent the related-protocol attacks, a type tag is prepended to
every message before signing it. The type-tags are 128-bit randomly every message before signing it. The type-tags are 128-bit randomly
chosen values, which prevents accidental type collisions with even chosen values, which prevents accidental type collisions with even
poorly designed protocols that do not use any type tags. Moreover, poorly designed protocols that do not use any type tags. Moreover,
the SEND protocol includes the sender's CGA address in all signed the SEND protocol includes the sender's CGA address in all signed
messages. This makes it even more difficult for an attacker to take messages. This makes it even more difficult for an attacker to take
signed messages from some other context and to replay them as SEND signed messages from some other context and to replay them as SEND
messages. messages.
Finally, some cautionary notes should be made about using CGA-based Finally, a strong cautionary note needs to be made about using CGA
authentication for other purposes than SEND. First, the other signatures for other purposes than SEND. First, the other protocols
protocols should include type tags and the sender address in all MUST include a type tag and the sender address in all signed messages
signed messages in the same way as SEND does. Because of the in the same way as SEND does. Each protocol MUST define its own type
possibility of related-protocol attacks, it is advisable to use the tag values as explained in Section 8. Moreover, because of the
public key only for signing and not for encryption. Second, CGA-based possibility of related-protocol attacks, the public key MUST be used
authentication is particularly suitable for securing neighbor only for signing and it MUST NOT be used for encryption. Second, the
discovery [RFC2461] and duplicate address detection [RFC2462] because minimum RSA key length of 384 bits may be too short for many
these are network-layer signaling protocols where IPv6 addresses are applications and the impact of key compromise on the particular
natural endpoint identifiers. In any protocol that aims to protect protocol needs to be evaluated. Third, CGA-based authorization is
higher-layer data, CGA-based authentication alone is not sufficient particularly suitable for securing neighbor discovery [RFC2461] and
and there must also be a secure mechanism for mapping higher-layer duplicate address detection [RFC2462] because these are network-layer
identifiers, such as DNS names, to IP addresses. signaling protocols where IPv6 addresses are natural endpoint
identifiers. In any protocol that uses other identifiers, such as DNS
names, CGA signatures alone are not a sufficient security mechanism.
There must also be a secure way of mapping the other identifiers to
IPv6 addresses. If the goal is not to verify claims about IPv6
addresses, CGA signatures are probably not the right solution.
8. IANA Considerations 8. IANA Considerations
This document defines a new CGA Message Type name space for use as This document defines a new CGA Message Type name space for use as
type tags in messages that may be signed using CGA signatures. The type tags in messages that may be signed using CGA signatures. The
values in this name space are 128-bit unsigned integers. Values in values in this name space are 128-bit unsigned integers. Values in
this name space are allocated on a First Come First Served basis this name space are allocated on a First Come First Served basis
[RFC2434]. IANA assigns new 128-bit values directly without a review. [RFC2434]. IANA assigns new 128-bit values directly without a review.
The requester SHOULD generate the new values with a strong The requester SHOULD generate the new values with a strong
random-number generator. Continuous ranges of at most 256 values can random-number generator. Continuous ranges of at most 256 values can
be requested provided that the 120 most significant bits of the be requested provided that the 120 most significant bits of the
skipping to change at page 19, line 5 skipping to change at page 17, line 10
allocates requested values without verifying the way in which they allocates requested values without verifying the way in which they
have been generated. The name space is essentially unlimited and any have been generated. The name space is essentially unlimited and any
number of individual values and ranges of at most 256 values can be number of individual values and ranges of at most 256 values can be
allocated. allocated.
CGA Message Type values for private use MAY be generated with a CGA Message Type values for private use MAY be generated with a
strong random-number generator without IANA allocation. strong random-number generator without IANA allocation.
This document does not define any new values in any name space. This document does not define any new values in any name space.
Normative References 9. References
9.1 Normative References
[I-D.ietf-send-ndopt] [I-D.ietf-send-ndopt]
Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P.
Nikander, "SEcure Neighbor Discovery (SEND)", Nikander, "SEcure Neighbor Discovery (SEND)",
draft-ietf-send-ndopt-03 (work in progress), January 2003. draft-ietf-send-ndopt-03 (work in progress), January 2003.
[RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003. (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280, Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002. April 2002.
[ITU.X690.2002] [ITU.X690.2002]
International Telecommunications Union, "Information International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, July 2002. X.690, July 2002.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[PKCS.1.2002]
RSA Laboratories, "RSA Encryption Standard, Version 2.1",
Public-Key Cryptography Standard PKCS 1, June 2002.
[FIPS.180-1.1995] [FIPS.180-1.1995]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", Federal Information Processing Standards Hash Standard", Federal Information Processing Standards
Publication FIPS PUB 180-1, April 1995, <http:// Publication FIPS PUB 180-1, April 1995, <http://
www.itl.nist.gov/fipspubs/fip180-1.htm>. www.itl.nist.gov/fipspubs/fip180-1.htm>.
Informative References 9.2 Informative References
[AAKMNR02] [AAKMNR02]
Arkko, J., Aura, T., Kempf, J., Mantyla, V., Nikander, P. Arkko, J., Aura, T., Kempf, J., Mantyla, V., Nikander, P.
and M. Roe, "Securing IPv6 neighbor discovery and router and M. Roe, "Securing IPv6 neighbor discovery and router
discovery", ACM Workshop on Wireless Security (WiSe 2002), discovery", ACM Workshop on Wireless Security (WiSe 2002),
Atlanta, GA USA , September 2002. Atlanta, GA USA , September 2002.
[Aura03] Aura, T., "Cryptographically Generated Addresses (CGA)", [Aura03] Aura, T., "Cryptographically Generated Addresses (CGA)",
6th Information Security Conference (ISC'03), Bristol, UK 6th Information Security Conference (ISC'03), Bristol, UK
, October 2003. , October 2003.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[MOV97] Menezes, A., van Oorschot, P. and S. Vanstone, "Handbook [MOV97] Menezes, A., van Oorschot, P. and S. Vanstone, "Handbook
of Applied Cryptography", CRC Press , 1997. of Applied Cryptography", CRC Press , 1997.
[MC02] Montenegro, G. and C. Castelluccia, "Statistically unique [MC02] Montenegro, G. and C. Castelluccia, "Statistically unique
and cryptographically verifiable identifiers and and cryptographically verifiable identifiers and
addresses", ISOC Symposium on Network and Distributed addresses", ISOC Symposium on Network and Distributed
System Security (NDSS 2002), San Diego, CA USA , February System Security (NDSS 2002), San Diego, CA USA , February
2002. 2002.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
skipping to change at page 22, line 5 skipping to change at page 19, line 17
Tuomas Aura Tuomas Aura
Microsoft Research Microsoft Research
Roger Needham Building Roger Needham Building
7 JJ Thomson Avenue 7 JJ Thomson Avenue
Cambridge CB3 0FB Cambridge CB3 0FB
United Kingdom United Kingdom
Phone: +44 1223 479708 Phone: +44 1223 479708
EMail: tuomaura@microsoft.com EMail: tuomaura@microsoft.com
Appendix A. Example of CGA Generation Appendix A. Example of CGA Generation
We generate a CGA with Sec=1 from the subnet prefix fe80:: and the We generate a CGA with Sec=1 from the subnet prefix fe80:: and the
following public key: following public key:
305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241 305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241
00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16 00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16
467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773 467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773
c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001 c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
The modifier is initialized to a random value 89a8 a8b2 e858 d8b8 The modifier is initialized to a random value 89a8 a8b2 e858 d8b8
skipping to change at page 24, line 5 skipping to change at page 20, line 22
Hash1=fd4a 5bf6 ffb4 ca6c. We form an interface identifier from this 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 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 and 7 (the "u" and "g" bits) to zero. The new interface identifier is
3c4a:5bf6:ffb4:ca6c. 3c4a:5bf6:ffb4:ca6c.
Finally, we form the IPv6 address fe80::3c4a:5bf6:ffb4:ca6c. This is Finally, we form the IPv6 address fe80::3c4a:5bf6:ffb4:ca6c. This is
the new CGA. No address collisions were detected this time. the new CGA. No address collisions were detected this time.
(Collisions are very rare.) The CGA Parameters data structure (Collisions are very rare.) The CGA Parameters data structure
associated with the address is the same as the input to Hash1 above. associated with the address is the same as the input to Hash1 above.
Appendix B. Acknowledgements Appendix B. Acknowledgements
The author gratefully acknowledges the contributions of Jari Arkko, The author gratefully acknowledges the contributions of Jari Arkko,
Francis DuPont, Pasi Eronen, Christian Huitema, Pekka Nikander, Francis Dupont, Pasi Eronen, Christian Huitema, James Kempf, Pekka
Michael Roe, Dave Thaler, and several other participants of the SEND Nikander, Michael Roe, Dave Thaler, and other participants of the
working group. SEND working group.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 52 change blocks. 
139 lines changed or deleted 241 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/