About: Cryptographically Generated Address is a research topic. Over the lifetime, 78 publications have been published within this topic receiving 1599 citations.
TL;DR: This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol, where IPv6 addresses are cryptographically generated addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters.
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. [STANDARDS-TRACK]
TL;DR: The socket API described in this document will be particularly useful for IPv6 applications that want to choose between temporary and public addresses, and for Mobile IPv6 aware applications thatwant to use the care-of address for communication.
Abstract: The IPv6 default address selection document (RFC 3484) describes the
rules for selecting source and destination IPv6 addresses, and
indicates that applications should be able to reverse the sense of
some of the address selection rules through some unspecified API.
However, no such socket API exists in the basic (RFC 3493) or advanced
(RFC 3542) IPv6 socket API documents. This document fills that gap
partially by specifying new socket-level options for source address
selection and flags for the getaddrinfo() API to specify address
selection based on the source address preference in accordance with
the socket-level options that modify the default source address
selection algorithm. The socket API described in this document will be
particularly useful for IPv6 applications that want to choose between
temporary and public addresses, and for Mobile IPv6 aware applications
that want to use the care-of address for communication. It also
specifies socket options and flags for selecting Cryptographically
Generated Address (CGA) or non-CGA source addresses. This memo
provides information for the Internet community.
TL;DR: A method for provisioning a shared key from the Access Router to the Mobile Node is defined to protect this signaling.
Abstract: Fast Mobile IPv6 requires that a Fast Binding Update is secured using
a security association shared between an Access Router and a Mobile
Node in order to avoid certain attacks. In this document, a method for
provisioning a shared key from the Access Router to the Mobile Node is
defined to protect this signaling. The Mobile Node generates a
public/private key pair using the same public key algorithm as for
SEND (RFC 3971). The Mobile Node sends the public key to the Access
Router. The Access Router encrypts a shared handover key using the
public key and sends it back to the Mobile Node. The Mobile Node
decrypts the shared handover key using the matching private key, and
the handover key is then available for generating an authenticator on
a Fast Binding Update. The Mobile Node and Access Router use the
Router Solicitation for Proxy Advertisement and Proxy Router
Advertisement from Fast Mobile IPv6 for the key exchange. The key
exchange messages are required to have SEND security; that is, the
source address is a Cryptographically Generated Address (CGA) and the
messages are signed using the CGA private key of the sending node.
This allows the Access Router, prior to providing the shared handover
key, to verify the authorization of the Mobile Node to claim the
address so that the previous care-of CGA in the Fast Binding Update
can act as the name of the key. [STANDARDS-TRACK]
TL;DR: The Shim6 architecture enables IPv6 multihoming without compromising the scalability of the global routing system by using provider aggregatable addresses and uses either cryptographically generated addresses or hash-based addresses.
Abstract: The Shim6 architecture enables IPv6 multihoming without compromising the scalability of the global routing system by using provider aggregatable addresses. To do so, hosts use different addresses as locators for data packet transmission, but present the same source and destination identifier pair to transport and upper layers. The components of this architecture are the Shim6 entity, which maps and translates upper-layer identifiers and locators for remote hosts; the Shim6 protocol, which exchanges mapping information between two hosts that communicate; and the REAP protocol, which monitors the existing unidirectional paths and finds new valid locator combinations in case of failure. To protect against new vulnerabilities this architecture may introduce compared to IPv6, Shim6 hosts use either cryptographically generated addresses or hash-based addresses.
TL;DR: This document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions and updates RFC 3972.
Abstract: This document defines a Type-Length-Value format for Cryptographically
Generated Address (CGA) Extensions. This document updates RFC 3972.
[STANDARDS-TRACK]