One document matched: draft-van-beijnum-cga-dhcp-interaction-00.txt
Network Working Group I. van Beijnum
Internet-Draft IMDEA Networks
Expires: May 15, 2008 November 12, 2007
Interactions between CGA and DHCPv6
draft-van-beijnum-cga-dhcp-interaction-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 May 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Cryptographically Generated Addresses as defined for IPv6 Secure
Neighbor Discovery are generated locally on the host using the CGA.
However, it can be desireable for other systems to be involved in the
generation and use of CGAs in a number of ways: offloading the heavy
cryptography for generating or validating CGAs, proxy-generation of
CGAs for hosts that don't support the CGA-related protocols
themselves or registration of CGA addresses for the purposes of
central address administration. When additional hosts are involved
in aspects of CGA, it's necessary to discover these other hosts
van Beijnum Expires May 15, 2008 [Page 1]
Internet-Draft Interactions between CGA and DHCPv6 November 2007
and/or additional configuration items such as the Sec value. The
DHCPv6 is a natural choice for doing this. This document provides an
overview of the opportunities and issues in this area.
1. Dissemination of CGA parameters through DHCPv6
Under normal circumstances, CGAs [RFC 3972] require three pieces of
information for their generation that may be subject to
administrative configuration: the Sec value that determines the
cryptographic strength of the hash in the interface identifier, the
public key, and the subnet prefix.
The Sec value looks like a good candidate for distribution using
DHCPv6, but the problem with that would be bidding down attacks.
Also, the point of a protocol like DHCP is to distribute settings
that are relevant to the current network location. Now that CGAs
have found uses beyond the local subnet in shim6 and MIPv6, it's not
obvious that the value of the Sec parameter is something that should
depend on the current location. Setting the Sec value
administratively through a mechanism that isn't location-dependent
could be a better option.
Still, it may be advantageous to have a mechanism to push out a Sec
value on the local network for SEND use if the bidding down problem
can be solved. A possible solution here could be a CGA Sec option
when DHCPv6 is deployed with authentication.
The public key (or public/private key pair) is not an obvious
candidate for inclusion in DHCPv6 configuration: either the host is
in charge of its own security and CGA generation, in which case it
should come up with its own keys, or it can't generate CGAs and it
has no need for the keys. There doesn't seem to be useful middle
ground here.
Hosts will generally receive the subnet prefix through router
advertisements. DHCPv6 is currently incapable of supplying just a
prefix: it can only supply the entire address. It may be worth
considering separating the subnet prefix bits from the interface
identifier bits, and allow the host to come up with the subnet prefix
and the server with the interface identifier, or the server with the
subnet prefix and the host with the interface identifier. The latter
would be useful in cases where a host generates CGAs but
administrative control over the prefix bits is desired beyond what
can be accomplished using stateless autoconfiguration.
Discussion: how does a DHCPv6 server know which prefixes (and with
which prefix lengths) are reachable on the subnet that a client
van Beijnum Expires May 15, 2008 [Page 2]
Internet-Draft Interactions between CGA and DHCPv6 November 2007
connects to?
2. Proxy generation of CGAs
Shim6 uses HBA, an extension to CGA, to secure the binding between
different addresses belonging to the same host. Proxy shim6 is a
proposal to allow a middlebox to perform shim6 processing so that
unmodified IPv6 hosts can enjoy shim6 benefits. For this, it's
necessary that the HBAs are generated on a different system than the
host holding the addresses in question. A similar situation may
present itself with other CGA uses. Proxy generation of CGAs/HBAs
can easily be done on a DHCPv6, which then assigns the resulting
address(es) to the host in question. The DHCPv6 protocol is able to
assign addresses to hosts, so this doesn't require a protocol
modification. However, in this case no other information than the
resulting address is communicated back to the host.
3. CGA proxying/offloading
Various aspects of CGA processing can be rather resource intensive.
The most obvious example of this is finding a hash with the requisite
number of lower bits set to 0 when the Sec parameter is larger than
0. Another example is a denial of service attack when the host
generates a challenge and a large number of responses comes back.
The host then needs to perform cryptographic checks for all incoming
packets. Another DoS vector would be a large number of incoming
challenges.
Since generating a hash is done with only public information, there
are almost no security issues with offloading this processing to
another host. (A very slight security risk is that the host doing
the processing gets to delay the use of a CGA, potentially until such
time that it is no longer secure.) So finding a CGA processing
server would be useful. An option for this could be added to DHCPv6.
However, DHCPv6 is a mechanism for configuration, not for service
discovery.
Proxy verification of incoming CGA-protected messages doesn't need
configuration: a middlebox that monitors the configuration can
perform the verification procedure and block all packets that fail
verification.
When the local host is challenged, it needs to perform a number of
cryptographic operations. These could be offloaded to another
system, but then there would have to be a secure channel towards that
other system. Presumably, the relatively small gains aren't worth
van Beijnum Expires May 15, 2008 [Page 3]
Internet-Draft Interactions between CGA and DHCPv6 November 2007
the extra complexity. However, MCGAs could be useful here. The
configuration and discovery requirements for that are best explored
in an MCGA document.
4. Address registration
The current DHCP model for IPv4 is that the DHCP server assigns
addresses. Many operators of enterprise networks and similarly
tightly administered networks have expressed the desire to hold on to
this model when moving to IPv6, because they don't want to have hosts
end up with essentially random IPv6 addresses.
However, the notion that a server assigns an address is for the most
part incompatible with CGA, although some exceptions are possible as
per the previous discussion. A useful way to give network
administrators most of what they want, while at the same time
retaining compatibility with normal CGA operation would be for the
host to generate one or more CGAs, and then register those with a
DHCPv6 server. The current DHCPv6 protocol allows for a host to
communicate a set of "preferred" addresses to the server. A host
could generate CGA addresses and then ask a DHCPv6 server for address
assignment, listing the CGA addresses in IA options. If the DHCPv6
server then grants the use of the requested addresses, the host is
able to use the generated CGAs. In the meantime, the DHCPv6 server
has had the opportunity to vet and log the address/host combination.
5. Certificate provisioning
CGAs secure the relationship between a public/private key pair
(certificate) and an address. To be useful in practice, it's
necessary to know which certificates or certificate chains are
trustworthy. DHCPv6 could be used to distribute this information,
but that would require secure DHCPv6 operation, i.e., DHCPv6
authentication. The DHCPv6 authentication methods defined in RFC
3315 require a pre-shared key. Such a security mechanism is likely
to be less secure than distributing certificates directly out-of-
band, but it may be more convenient, especially is DHCPv6
authentication is used for other reasons to begin with. Because the
security of pre-shared keys is limited anyway and the DHCPv6 option
space is restricted, it could be useful to exchange just the
fingerprints of certificates rather than the certificates in their
entirety.
van Beijnum Expires May 15, 2008 [Page 4]
Internet-Draft Interactions between CGA and DHCPv6 November 2007
6. IANA considerations
None.
7. Security considerations
Security considerations are discussed throughout this document.
Appendix A. Document and Author Information
The latest version of this document will always be available at
http://www.muada.com/drafts/. Please direct questions and comments
to the CGA-EXT mailinglist
(https://www1.ietf.org/mailman/listinfo/cga-ext) or directly to the
author.
Author's Address
Iljitsch van Beijnum
IMDEA Networks
Av. Universidad 30
Leganes, Madrid 28911
ES
Phone: +34-91-6246245
Email: iljitsch@muada.com
van Beijnum Expires May 15, 2008 [Page 5]
Internet-Draft Interactions between CGA and DHCPv6 November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
van Beijnum Expires May 15, 2008 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-23 04:12:26 |