One document matched: draft-ietf-send-cga-00.txt
IETF Securing Neighbor Discovery WG Tuomas Aura
INTERNET DRAFT Microsoft Research
Expires December 2003 June 2003
Cryptographically Generated Addresses (CGA)
draft-ietf-send-cga-00.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 13, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes a method for binding a public signature key
to an IPv6 address in Secure Neighbor Discovery (SEND).
Cryptographically Generated Addresses (CGA) are IPv6 addresses
where the interface identifier is generated by computing a
cryptographic one-way hash function from the address owner's public
key and auxiliary parameters. The binding between the public key
and the address can be verified by re-computing the hash value and
by comparing the hash with the interface identifier. SEND protocol
messages are protected with an Authentication Header (AH) that
contains the public key and the auxiliary parameters and is signed
with the corresponding private key. The protection works without a
certification authority or other security infrastructure.
Table of Contents
Aura Expires December 13, 2003 [Page 1]
INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003
Status of This Memo...............................................1
Copyright Notice..................................................1
Abstract..........................................................1
Table of Contents.................................................1
1. Introduction...................................................2
2. The CGA Address Format.........................................3
3. The CGA Parameters and the Hash Values.........................4
4. CGA Generation.................................................5
5. CGA Verification...............................................6
6. The CGA Authorization Mechanism for SEND.......................8
6.1 Sending SEND Messages........................................8
6.2 Receiving SEND messages......................................9
7. Security Considerations........................................9
7.1 Security Goals and Limitations...............................9
7.2 Hash extension..............................................10
7.3 Privacy Considerations......................................12
8. IANA Considerations...........................................13
Acknowledgments..................................................13
Intellectual Property Statement..................................13
Normative References.............................................13
Informative References...........................................14
Appendix A. Example of CGA Generation..........................14
Appendix B. Changes since draft-aura-cga-pre01.................14
Author's Address.................................................15
Intellectual Property Statement..................................15
Full Copyright Statement.........................................15
1. Introduction
This document specifies a method for securely associating a public
key with an IPv6 address in the secure neighbor discovery (SEND)
protocol [AKSZ03]. The basic idea is to generate the interface
identifier (i.e. rightmost 64 bits) of the IPv6 address by
computing a cryptographic hash of the public key. This kind of IPv6
addresses are called cryptographically generated addresses (CGA).
The corresponding private key can then be used to sign SEND
messages.
More specifically, this document specifies
- how to create CGA addresses from the cryptographic hash of a
public key and auxiliary parameters,
- how to transfer the public key and the auxiliary parameters
in a signed SEND message, and
- how to verify the association between the public key and the
IPv6 address.
Aura Expires December 13, 2003 [Page 2]
INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003
In order to verify the association between the address and the
public key, the verifier needs to know the address itself, the
public key, and the values of the auxiliary parameters. No
additional security infrastructure, such as a public key
infrastructure (PKI), certification authorities, or other trusted
servers, is needed.
The address format and the CGA parameter format are defined in
Sections 2 and 3. Detailed algorithms for generating addresses and
for verifying them are given in Sections 4 and 5, respectively.
Section 6 defines a method for authenticating SEND messages where
the source address is a CGA address.
The security considerations in Section 7 include limitations of
CGA-based authentication, the reasoning behind the hash extension
technique that enables effective hash lengths above the 64-bit
limit of the interface identifier, and the implications CGA
addresses on privacy.
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to
be interpreted as described in [Bra97].
2. The CGA Address Format
When talking about addresses, this document refers to IPv6
addresses where the leftmost 64 bits of a 128-bit address form the
subnet prefix and the rightmost 64 bits of the address form the
interface identifier. [HD03]
A cryptographically generated address (CGA) has a security
parameter (Sec), which determines its strength against brute-force
attacks. The security parameter is a 3-bit unsigned integer and it
is encoded in the three leftmost bits (i.e. bits 0-2) of the
interface identifier. This can be written as:
Sec = (interface identifier & 0xe000000000000000) >> 61
The CGA address is associated with a set of parameters, which
consist of a public key and auxiliary parameters. Two hash values
Hash1 and Hash2 (64 and 112 bits, respectively) are computed from
the parameters. The formats of the public key and auxiliary
parameters and the inputs to the hash functions are defined in
Section 3.
A cryptographically generated address (CGA) is defined as an IPv6
address where the 16*Sec leftmost bits of the second hash value
Hash2 are zero, and the rightmost 64 bits of the first hash value
Hash1 equal the interface identifier of the address. The three
Aura Expires December 13, 2003 [Page 3]
INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003
leftmost bits of the address, which encode the security parameter
Sec, and the "u" and "g" bits are ignored in the comparison. The
"u" and "g" bits (i.e. bits 6 and 7 of the interface identifier)
must both be zero.
The above definition can be stated in terms of the following two
bit masks:
Mask1 (112 bits) = 0x0000000000000000000000000000 if Sec=0,
0xffff000000000000000000000000 if Sec=1,
0xffffffff00000000000000000000 if Sec=2,
0xffffffffffff0000000000000000 if Sec=3,
0xffffffffffffffff000000000000 if Sec=4,
0xffffffffffffffffffff00000000 if Sec=5,
0xffffffffffffffffffffffff0000 if Sec=6, and
0xffffffffffffffffffffffffffff if Sec=7
Mask2 (64 bits) = 0xfcfffffffffffff8
Mask3 (64 bits) = 0xfffffffffffffff8
A cryptographically generated address is an IPv6 address for which
the following two equations hold:
Hash1 & Mask2 == interface identifier & Mask3
Hash2 & Mask1 == 0x0000000000000000000000000000
3. The CGA Parameters and the Hash Values
Each CGA address is associated with a DER-encoded [ITU02] ASN.1
data item of the type CGAParameters:
CGAParameters ::= SEQUENCE {
auxParameters CGAAuxParameters,
publicKey SubjectPublicKeyInfo }
CGAAuxParameters ::= SEQUENCE {
modifier OCTET STRING (SIZE 16),
subnetPrefix OCTET STRING (SIZE 8),
collisionCount INTEGER (0..2) }
The publicKey data item contains the address owner's public key.
The ASN.1 type SubjectPublicKeyInfo is defined in the Internet
X.509 certificate profile [HFPS02]. In addition to the public key,
there are three auxiliary parameters:
o a 16-octet modifier, which can get any value
Aura Expires December 13, 2003 [Page 4]
INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003
o the 8-octet subnetPrefix, which is equal to the subnet prefix
of the CGA address, and
o collisionCount, which can get values 0, 1 and 2.
The two hash values are computed with the SHA-1 hash algorithm
[NIS95] from the DER-encoded CGAParameters data item. When
computing Hash1, the input to the SHA-1 algorithm is simply the
DER-encoding. The 64-bit Hash1 is obtained by taking the leftmost
64 bits of then 160-bit SHA-1 hash value.
When computing Hash2, the value of the subnetPrefix data item is
set to 8 zero octets and the value of the collisionCount data item
is set to 0. The 112-bit Hash1 is obtained by taking the leftmost
112 bits of the 160-bit SHA-1 hash value.
4. CGA Generation
The process of generating a new CGA address takes three input
values: a 64-bit subnet prefix, the public key of the address
owner, and the security parameter Sec, which is an unsigned 3-bit
integer. The result is a new CGA address and the associated
parameters. The cost of generating a new CGA address depends on the
security parameter Sec, which gets values from 0 to 7.
A CGA address and associated CGA parameters SHOULD be generated as
follows:
(1) Create an ASN.1 data item of type CGAParameters. Set the
publicKey data value to the address owner's public key. Set
the modifier data value to 16 random octets. Set the
subnetPrefix data value to 8 zero octets. Set the
collisionCount data value to zero.
(2) DER-encode the CGAParameters data value. Execute the SHA-1
algorithm on the DER-encoded CGAParameters data value. Take
the 112 leftmost bits of the SHA-1 hash value. The result is
Hash2.
(3) Compare the 16*Sec leftmost bits of Hash2 with zero. If they
are all zero (or if Sec=0), continue with the step (4).
Otherwise, increment the modifier data value (as if its
content octets were a 128-bit integer) and go back to step
(2).
(4) Set the 8-octet subnetPrefix data value in the encoded
CGAParameters data item to the given subnet prefix.
Aura Expires December 13, 2003 [Page 5]
INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003
(5) Execute the SHA-1 algorithm on the new DER-encoded
CGAParameters data value. Take the 64 leftmost bits of the
SHA-1 hash value. The result is Hash1.
(6) Form an EUI-64 interface identifier by setting the "u" and
"g" bits in Hash1 both to 0 and the three leftmost bits of
the address to the value Sec.
(7) Concatenate the 64-bit subnet prefix and the EUI-64
interface identifier to form a 128-bit IPv6 address.
(8) If an address collision is detected, increment the
collisionCount data value in the DER-encoded CGAParameters
data item and go back to step (5). However, after three
collisions, stop and report the error.
In order to avoid trying the same modifier values repeatedly, it is
RECOMMENDED to that the initial modifier value in step (1) is
chosen randomly and that the modifier is incremented in step (3) as
if it were an unsigned 128-bit integer. When incrementing the
modifier, the octet order can be chosen arbitrarily and overflows
can be ignored. The quality of the random number generator is not
important as long as the same values are not repeated frequently.
However, if privacy enhancement (see Section 7.3) is required, the
random numbers should be unpredictable and unlinkable.
For Sec=0, the above algorithm is deterministic and relatively
fast. Nodes that implement CGA generation MAY set the security
parameter Sec to always 0. In that case, steps (2)-(3) of the
generation algorithm can be skipped.
For Sec values greater than 0, the above algorithm is not
guaranteed to terminate after a certain number of iterations. The
brute-force search in steps (2)-(3) takes O(2^(16*Sec)) iterations
to complete. Implementations SHOULD take into account the fact that
generating CGA addresses with high Sec values will take
considerable time and that generating addresses with the highest
Sec values is infeasible with today's technology.
If the subnet prefix of the address changes but the address owner's
public key does not, the old modifier value MAY be reused. If it is
reused, the algorithm SHOULD be started from step (4). This avoids
repeating the expensive search for an acceptable modifier value.
5. CGA Verification
CGA verification takes two inputs: an IPv6 address and a DER-
encoded CGAParameters data item. The verification either succeeds
or fails.
Aura Expires December 13, 2003 [Page 6]
INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003
The CGA MUST be verified with the following steps:
(1) Check that the "g" and "u" bits in the interface identifier
are both zero. If either bit is non-zero, the CGA
verification fails.
(2) Read the security parameter Sec from the three leftmost bits
of the 64-bit interface identifier of the address. (Sec is
an unsigned 3-bit integer.)
(3) Decode the DER-encoded CGAParameters data item. Check that
the subnetPrefix data value is equal to the subnet prefix
(i.e. leftmost 64 bits) of the address. Check that the
collisionCount value is 0, 1 or 2. The CGA verification
fails if the decoding of the CGA parameters fails, if the
subnetPrefix value does not match the address, or if the
collisionCount value is out of range.
(4) Execute the SHA-1 algorithm on the DER-encoded CGAParameters
data value. Take the 64 leftmost bits of the SHA-1 hash
value. The result is Hash1.
(5) Compare Hash1 with the interface identifier (i.e. the
rightmost 64 bits) of the address. Differences in the "g"
and "u" bits and in the three leftmost bits are ignored. If
the 64-bit values differ (other than in the five ignored
bits), the CGA verification fails.
(6) Set the subnetPrefix data value in the DER-encoded
CGAParameters data item to 8 zero octets and the
collisionCount data value to 0.
(7) Execute the SHA-1 algorithm on the new DER-encoded
CGAParameters data value. Take the 112 leftmost bits of the
SHA-1 hash value. The result is Hash2.
(8) Compare the 16*Sec leftmost bits of Hash2 with zero. If any
one of them is non-zero, the CGA verification fails.
Otherwise, the verification succeeds. (If Sec=0, the CGA
verification never fails at this step.)
If the verification succeeds, the verifier knows that the publicKey
field in the CGAParameters data value is the authentic public key
of the address owner.
All nodes that implement CGA verification MUST be able to process
all security parameter values Sec = 0, 1, 2, 3, 4, 5, 6, 7. The
verification procedure is relatively fast and always requires a
Aura Expires December 13, 2003 [Page 7]
INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003
constant amount of computation. If Sec=0, the verification never
fails in steps (6)-(8) and these steps MAY be skipped.
After the verification succeeds or fails, the verifier SHOULD
discard the Sec, modifier and collisionCount values and not use
them for any further purpose. In particular, the verifier should
set the minSec value in the inbound AH_RSA_Sig security association
to zero (see [AKSZ03] Section 7.1.3). Future extensions of this
specification may define situations where a it is acceptable for
the verifier to set higher minSec values.
6. The CGA Authorization Mechanism for SEND
Nodes that use Secure Neighbor Discovery (SEND) protocol MUST
process outbound and inbound SEND messages as specified in
[AKSZ03]. This section gives additional guidance on using the CGA
authorization mechanism in these messages.
6.1 Sending SEND Messages
sNodes that use the Secure Neighbor Discovery (SEND) protocol and
use CGA addresses MUST use the format of the CGA addresses as
described in Section 2, SHOULD generate the addresses as described
in Section 4.
The public key used for the address generation MUST have the object
identifier sha1WithRSAEncryption [JK03]. The RSA public key MUST be
at least 1024 bits long.
A node that has a CGA address MAY use the CGA authorization
mechanism when it sends secure Neighbor Solicitations (NS),
Neighbor Advertisements (NA), Router Solicitations (RS) and Router
Advertisements (RA) where the IP source address is a CGA address
and the source link-layer address option is present in the message.
Note that the node MAY use trusted-root authorization mechanism
instead or in addition to the CGA authorization mechanism
authentication. The mechanism to be used is determined by the
node's IPSec configuration.
When sending a secure NA, NS, RA or RS message, the node MUST
protect the message with an IPSec Authentication Header (AH) that
uses the AH_RSA_Sig transform defined in [AKSZ03]. Within the AH,
the contents of the Key Information field are represented as ASN.1
DER-encoded data item of the following type:
SendKeyInformation ::= SEQUENCE {
cgaParameters CGAParameters OPTIONAL,
signerInfo SubjectPublicKeyInfo OPTIONAL }
Aura Expires December 13, 2003 [Page 8]
INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003
(The normative definition of the type SendKeyInformation is in
[AKSZ03].)
When the CGA authorization mechanism is used in a SEND message, the
cgaParameters field in SendKeyInformation MUST be present and its
value MUST be the same CGAParameters data value that was used for
generating the IP source address of the SEND message. The signature
in the AH MUST be verifiable with the public key that is sent in
the CGAParameters.
6.2 Receiving SEND messages
Received SEND messages MUST be processed as specified in Section
7.1.6 of [AKSZ03]. If the security association requires the
verification of the CGA property, the receiver must verify the MUST
verify the source address of the packet as described in Section 5.
The inputs for the algorithm are the source address of the packet
and the contents of the CGAParameters structure from the Key
Information field.
If the CGA verification is successful, the node goes on to verify
the signature in the AH as defined in [AKSZ03]. On the other hand,
if the CGA verification fails, the recipient MUST stop processing
the SEND message and ignore its contents.
7. Security Considerations
7.1 Security Goals and Limitations
The purpose of CGA addresses is to prevent stealing and spoofing of
IPv6 addresses in the secure neighbor discovery protocol. The
public key of the address owner is bound cryptographically to the
address. The address owner can use the corresponding private key to
assert its ownership of the address and to sign SEND messages sent
from the address.
It is important to understand that that attacker can create a new
address from an arbitrary subnet prefix and its own public key.
What the attacker cannot do is to impersonate somebody else's
address. This is because the attacker would have to find a
collision of the cryptographic hash value Hash1. (The property of
the hash function needed here is called second pre-image resistance
or weak collision resistance.)
For each valid CGAParameters data value, there are Sec different
CGA addresses that match the value. This is because decrementing
the Sec value in the three leftmost bits of the interface
identifier does not invalidate the address. In SEND, this fact does
not have any security or implementation implications.
Aura Expires December 13, 2003 [Page 9]
INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003
Another limitation of CGA addresses is that there is no mechanism
for proving that an address is not a CGA address. Thus, an attacker
could take someone else's CGA address and present it as a non-CGA
address (e.g. as an RFC-3041 address). To avoid being tricked,
every node must either accept neighbor discovery messages with CGA-
based authentication or unauthenticated ones, but not both. This
effectively means that secure and insecure nodes on the same
network cannot talk directly to each other. Nodes can, however, be
configured to use different subnet prefixes for CGA and non-CGA
addresses.
Finally, a cautionary note should be made about using CGA-based
authentication for other purposes than SEND. CGA-based
authentication is particularly suitable for securing neighbor
discovery [NN98] and duplicate address detection [TN98] because
these are network-layer signaling protocols where IPv6 addresses
are natural endpoint identifiers. In any protocol that aims to
protect higher-layer data, CGA-based authentication alone is not
sufficient but there must also be a secure mechanism for mapping
higher-layer identifiers, such as DNS names, to IP addresses.
7.2 Hash extension
As computers become faster, the 64 bits of the interface identifier
will not be sufficient to prevent attackers from searching for hash
collisions. It helps somewhat that we include the subnet prefix of
the address in the hash input. This prevents the attacker from
using a single pre-computed database to attack addresses with
different subnet prefixes. The attacker needs to create a separate
database for each subnet prefix. Link-local addresses are, however,
left vulnerable because the same subnet prefix is used by all IPv6
nodes.
In the long term, some kind of hash extension technique must be
used to counter the effect of faster computers. Otherwise, the CGA
technology could become outdated after 5-20 years. The idea in this
document is to increase the cost of both address generation and
brute-force attacks by the same parameterized factor while keeping
the cost of address use and verification constant. This provides
protection also for link-local addresses. Introduction of the hash
extension is the main difference between this document and earlier
CGA proposals [OR01][Nik01][MC02].
To achieve the effective extension of the hash length, the input to
the second hash function Hash2 is modified (by changing the
modifier value) until the leftmost 16*Sec bits of Hash2 are zero.
This increases the cost of address generation approximately by a
factor of 2^(16*Sec). It also increases the cost of brute-force
Aura Expires December 13, 2003 [Page 10]
INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003
attacks by the same factor. That is, the cost of creating a
certificate that binds the attacker's public key with somebody
else's address is increased from O(2^59) to O(2^(59+16*Sec)). The
address generator may choose the security parameter Sec depending
on its own computational capacity, perceived risk of attacks, and
the expected lifetime of the address. Currently, Sec values between
0 and 2 are sufficient for most IPv6 nodes. As computers become
faster, higher Sec values will slowly become useful.
Theoretically, if no hash extension is used (i.e. Sec=0) and a
typical attacker is able to tap into N local networks at the same
time, an attack against link-local addresses is N times as
efficient as an attack against addresses of a specific network. The
effect could be countered by using a slightly higher Sec value for
link-local addresses. When higher Sec values (such that 2^(16*Sec)
> N) are used for all addresses, the relative advantage of
attacking link-local addresses becomes insignificant.
The effectiveness of the hash extension depends of the assumption
that the computational capacity of the attacker and the address
generator will grow and the same (potentially exponential) rate.
This is clearly not true if the addresses are generated on low-end
mobile devices. But there is no reason for doing so. The expensive
part of the address generation (steps (2)-(3) of the generation
algorithm) may be delegated to a more powerful computer. Moreover,
this work can be done in advance or offline, rather than in real
time when a new address is needed.
In order to make it possible for mobile nodes whose subnet prefix
changes frequently to use Sec values greater than 0, we have
decided not to include the subnet prefix in the input of Hash2. The
result is weaker than if the subnet prefix were included in the
input of both hashes. On the other hand, our scheme is at least as
strong as using the hash extension technique without including the
subnet prefix in either hash. It is also at least as strong as not
using the hash extension but including the subnet prefix. This
trade-off was made because mobile nodes frequently move to insecure
networks where they are at the risk of denial-of-service (DoS)
attacks, for example, during the duplicate address detection
procedure.
In most networks, the goal of secure neighbor discovery and CGA-
based authentication is to prevent denial-of-service attacks.
Therefore, it is usually sensible to start by using a low Sec value
and to replace addresses with stronger ones only when denial-of-
service attacks based on brute-force search become a significant
problem. (If CGA address were used as a part of a strong
authentication or secrecy mechanisms, it would be necessary to
start with higher Sec values.)
Aura Expires December 13, 2003 [Page 11]
INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003
The collisionCount value is used to modify the input to Hash1 if
there is an address collision. It is important not to allow
collisionCount values higher than 2. First, it is extremely
unlikely that three collisions would occur and the reason is
certain to be either a configuration or implementation error or a
denial-of-service attack. (When the SEND protocol is used, the
deliberate collisions caused by a DoS attacker are detected and
ignored.) Second, an attacker who is doing a brute-force search to
match a given CGA address can try all different values of
collisionCount without repeating the brute-force search for the
modifier value. Thus, the more different values are allowed for
collisionCount, the less effective the hash-extension technique is
in preventing brute-force attacks.
7.3 Privacy Considerations
CGA addresses can give the same level pseudonymity as the IPv6
address privacy extensions defined in RFC 3041 [ND01]. An IP host
can generate multiple pseudorandom CGA addresses by executing the
CGA generation algorithm of Section 4 multiple times and by using
every time a different random or pseudorandom initial value for the
modifier. The host should change its address periodically as in
[ND01]. When privacy protection is needed, the (pseudo)random
number generator used in address generation SHOULD be strong enough
to produce unpredictable and unlinkable values.
There are two apparent limitations to this privacy protection.
However, as we will explain below, neither limitation is very
serious.
First, the high cost of address generation may prevent hosts that
use a high Sec value from changing their address frequently. This
problem is mitigated by the fact that the expensive part of the
address generation may be done in advance or offline, as explained
in the previous section. It should also be noted that the nodes
that benefit most from high Sec values (e.g. DNS servers, routers,
and data servers) usually do not require pseudonymity, while the
nodes that have high privacy requirements (e.g. client PCs and
mobile hosts) are unlikely targets for expensive brute-force
attacks and can do with lower Sec values.
Second, the public key of the address owner is revealed in the
authenticated SEND messages. This means that if the address owner
wants to be pseudonymous towards the nodes in the local links that
it accesses, it should not only generate a new address but also a
new public key. With typical local-link technologies, however, a
node's link-layer address makes it possible for others to correlate
its appearances of the local link. As long as the node keeps using
Aura Expires December 13, 2003 [Page 12]
INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003
the same link-layer address, it makes little sense to ever change
the public key for privacy reasons.
8. IANA Considerations
No new IANA-allocated values are defined in this document.
Acknowledgments
Many of the ideas in this draft were influenced by Michael Roe,
Christian Huitema and Pekka Nikander. Jari Arkko, Pasi Eronen and
other participants in the IETF working group made many helpful
comments.
Intellectual Property Statement
Several IPR claims have been made about the technology described in
this document.
Normative References
[AKSZ03] Jari Arkko, James Kempf, Bill Sommerfeld, and Brian
Zill. Secure neighbor discovery (SEND). Internet-Draft draft-ietf-
send-ipsec-01.txt, IETF Securing Neighbor Discovery Working Group,
June 2003. Work in progress.
[Bra97] Scott Bradner. Key words for use in RFCs to indicate
requirement levels. RFC 2119, IETF Network Working Group, March
1997.
[HD03] Robert M. Hinden and Stephen E. Deering. IP version 6
addressing architecture. RFC 3513, IETF Network Working Group,
April 2003.
[HFPS02] Russell Housley, Warwick Ford, Tim Polk, and David
Solo. Internet X.509 public key infrastructure certificate and
certificate revocation list (CRL) profile. RFC 3280, IETF Network
Working Group, April 2002.
[ITU02] International Telecommunication Union. ITU-T recommendation
X.690, information technology -- ASN.1 encoding rules:
Specification of basic encoding rules (BER), canonical encoding
rules (CER) and distinguished encoding rules (DER), July 2002. Also
appeared as ISO/IEC International Standard 8825-1.
[JK03] Jakob Jonsson and Burt Kaliski. Public-key cryptography standards
(PKCS) #1: RSA cryptography specifications version 2.1. RFC 3447, IETF
Network Working Group, February 2003.
Aura Expires December 13, 2003 [Page 13]
INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003
[NIS95] Secure hash standard. Federal Information Processing
Standards Publication FIPS PUB 180-1, National Institute of
Standards and Technology, Gaithersburg, MD USA, April 1995.
Informative References
[AAK+02] Jari Arkko, Tuomas Aura, James Kempf, Vesa-Matti
M„ntyl„, Pekka Nikander, and Michael Roe. Securing IPv6 neighbor
discovery and router discovery. In Proc. 2002 ACM Workshop on
Wireless Security (WiSe), pages 77-86, Atlanta, GA USA, September
2002. ACM Press.
[MC02] Gabriel Montenegro and Claude Castelluccia. Statistically
unique and cryptographically verifiable identifiers and addresses.
In Proc. ISOC Symposium on Network and Distributed System Security
(NDSS 2002), San Diego, February 2002.
[ND01] Thomas Narten and Richard Draves. Privacy extensions for
stateless address autoconfiguration in IPv6. RFC 3041, IETF Network
Working Group, January 2001.
[NN98] Thomas Narten, Erik Nordmark, and William Allen Simpson.
Neighbor discovery for IP version 6 (IPv6). RFC 2461, IETF Network
Working Group, December 1998.
[Nik01] Pekka Nikander. A scaleable architecture for IPv6 address
ownership. Internet-draft, March 2001. Work in Progress.
[OR01] Greg O'Shea and Michael Roe. Child-proof authentication for
MIPv6 (CAM). ACM Computer Communications Review, 31(2), April 2001.
[TN98] Susan Thomson and Thomas Narten. IPv6 stateless address
autoconfiguration. RFC 2462, IETF Network Working Group, December
1998.
Appendix A. Example of CGA Generation
TBW
Appendix B. Changes since draft-aura-cga-pre01
This appendix is intended only for the readers who reviewed a
preliminary version of this draft titled draft-aura-cga-pre01.
o The number of zero bits in hash 2 is 16*Sec (was 12*Sec),
length of Hash2 is 112 bits (was 84 bits), and the length of
modifier 16 octets (was 12 octets). Makes coding easier and
extends the maximal hash length.
Aura Expires December 13, 2003 [Page 14]
INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003
o Sec is now encoded in the three leftmost bits of the 64-bit
interface identifier. Earlier, it was encoded in the three
rightmost bits. Using the rightmost bits would distort the
distribution of solicited-node multicast addresses.
o Changed the order of the publicKey and auxParameters fields
in CGAParameters. This makes decoding without an ASN.1
compiler easier because the fixed-length fields come first.
o sha1WithRSAEncryption is now the only allowed signature
algorithm. Minimum key length is 1024 bits. The minimum key
length makes the decoding of CGAParameters easier.
Author's Address
Tuomas Aura
Microsoft Research
7 J J Thomson Avenue
Cambridge, CB3 0FB
United Kingdom
Phone: +44 1223 479708
Email: tuomaura@microsoft.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF
Executive Director.
Full Copyright Statement
Aura Expires December 13, 2003 [Page 15]
INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Aura Expires December 13, 2003 [Page 16] | PAFTECH AB 2003-2026 | 2026-04-22 13:47:27 |