Cryptographically Generated Addresses (CGA)
RFC 3972
Document | Type |
RFC - Proposed Standard
(March 2005; No errata)
Was draft-ietf-send-cga (send WG)
|
|
---|---|---|---|
Author | Tuomas Aura | ||
Last updated | 2013-03-02 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3972 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Margaret Cullen | ||
Send notices to | (None) |
Network Working Group T. Aura Request for Comments: 3972 Microsoft Research Category: Standards Track March 2005 Cryptographically Generated Addresses (CGA) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. Aura Standards Track [Page 1] RFC 3972 Cryptographically Generated Addresses March 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. CGA Format . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. CGA Parameters and Hash Values . . . . . . . . . . . . . . . . 5 4. CGA Generation . . . . . . . . . . . . . . . . . . . . . . . . 6 5. CGA Verification . . . . . . . . . . . . . . . . . . . . . . . 9 6. CGA Signatures . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7.1. Security Goals and Limitations . . . . . . . . . . . . . 12 7.2. Hash Extension . . . . . . . . . . . . . . . . . . . . . 13 7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 15 7.4. Related Protocols . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 A. Example of CGA Generation. . . . . . . . . . . . . . . . . 20 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Full Copyright Statements. . . . . . . . . . . . . . . . . . . . . 22 1. Introduction This document specifies a method for securely associating a cryptographic public key with an IPv6 address in the Secure Neighbor Discovery (SEND) protocol [RFC3971]. The basic idea is to generate the interface identifier (i.e., the rightmost 64 bits) of the IPv6 address by computing a cryptographic hash of the public key. The resulting IPv6 address is called a cryptographically generated address (CGA). The corresponding private key can then be used to sign messages sent from the address. An introduction to CGAs and their application to SEND can be found in [Aura03] and [AAKMNR02]. This document specifies: o how to generate a CGA from the cryptographic hash of a public key and auxiliary parameters, o how to verify the association between the public key and the CGA, and o how to sign a message sent from the CGA, and how to verify the signature. Aura Standards Track [Page 2] RFC 3972 Cryptographically Generated Addresses March 2005 To verify the association between the address and the public key, the verifier needs to know the address itself, the public key, and the values of the auxiliary parameters. The verifier can then go on to verify messages signed by the owner of the public key (i.e., the address owner). No additional security infrastructure, such as a public key infrastructure (PKI), certification authorities, or other trusted servers, is needed. Note that because CGAs themselves are not certified, an attacker can create a new CGA from any subnet prefix and its own (or anyone else's) public key. However, the attacker cannot take a CGA created by someone else and send signed messages that appear to come from theShow full document text