Network Working Group P. Nikander
Internet-Draft Ericsson Research Nomadiclab
Expires: December 18, 2003 June 19, 2003
Secure Neighbor Discovery using separate CGA extension header
draft-nikander-send-ipsec-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 18, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The Secure Neighbor Discovery (SEND) Working Group has produced an
Internet Draft that proposes to use an IPsec AH header that carries
both a public key and a signature. However, based on the recent
discussion at the mailing lists it seems that such a usage of AH is
considered inappropriate at least by some members of the IPSEC WG.
In this draft we introduce an alternative method, where a separate
extension header is used to carry the public key, and the AH header
only contains a signature.
Nikander Expires December 18, 2003 [Page 1]
Internet-Draft SEND with CGA ext June 2003
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Modifications to Neighbor Discovery . . . . . . . . . . . . 4
3. CGA based Inline Key Management Protocol (IKMP) . . . . . . 5
3.1 Processing rules for outgoing packets . . . . . . . . . . . 6
3.2 Processing rules for incoming packets . . . . . . . . . . . 6
4. Certificate based Key Management Protocol (KMP) . . . . . . 8
5. IPsec Extensions . . . . . . . . . . . . . . . . . . . . . . 9
5.1 The AH_RSA Algorithm . . . . . . . . . . . . . . . . . . . . 9
5.1.1 Reserved SPI Number . . . . . . . . . . . . . . . . . . . . 9
5.2 AH_RSA Security Associations . . . . . . . . . . . . . . . . 9
5.3 Processing Rules for Senders . . . . . . . . . . . . . . . . 9
5.4 Processing Rules for Receivers . . . . . . . . . . . . . . . 9
6. Other IPsec Extensions . . . . . . . . . . . . . . . . . . . 11
6.1 Destination Agnostic Security Associations . . . . . . . . . 11
6.2 ICMP Type Specific Selectors . . . . . . . . . . . . . . . . 11
7. Other functionality . . . . . . . . . . . . . . . . . . . . 12
Normative References . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
A. IPR Considerations . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . 15
Nikander Expires December 18, 2003 [Page 2]
Internet-Draft SEND with CGA ext June 2003
1. Overview
IPsec AH is used in to protect Neighbor and Router Discovery
messages. This specification introduces a new extension header,
which creates a new Inline Key Management Protocol (IKMP), a new
public key algorithm for IPsec AH, a couple of small modifications to
the proposed IPsec selectors in AHbis [4], and an address ownership
proof mechanism. This document does not propose any changes to the
authorization delegation discovery process presented in the official
working group draft. [5]
The components of the solution specified in this document are as
follows:
o IPsec AH is used to protect all messages relating to Neighbor and
Router discovery.
o Cryptographically Generated Addresses are used to assure that the
sender of a Neighbor or Router Advertisement is the owner of an
the claimed address. Alternatively, certificates could be used
for this, using a certificate based KMP, but such protocol is not
specified in this document. A public-private key pair needs to be
generated by all nodes before they can claim an address.
o IPsec security policy database is configured to provide the
protection. Note that such configuration may take place manually
or the operating system may perform it automatically upon enabling
Secure Neighbor Discovery.
Security Associations are created on the fly, using the IKMP.
This specification introduces extensions to the required selectors
used in security policy database entries. This is necessary in
order to enable the protection of specific ICMP message types,
while leaving other messages unprotected. Additionally, it must be
possible to select the correct Security Association (SA) based on
the source address in an incoming packet.
o A new IPv6 extension header is used to generate public key based
security associations on the fly. The trust to the public key is
established either with an authorization delegation process (which
is unspecified in this document) or the presented address
ownership proof mechanism, depending on configuration and the type
of the message protected.
o A new algorithm for IPsec AH allows public keys to be used on a
security association. Symmetric session keys are not used, public
key signatures are used instead.
Nikander Expires December 18, 2003 [Page 3]
Internet-Draft SEND with CGA ext June 2003
2. Modifications to Neighbor Discovery
This document proposes the same modifications to the IPv6 ND protocol
than the official working group draft [5] does, namely the following:
o The use of the unspecified address as a source address is
discouraged.
o The solicited-node multicast address is replaced with the
securely-solicited-node multicast address.
o The Nonce option is required in all Neighbor Discovery
solicitations, and for all solicited advertisements.
o Proxy Neighbor Discovery is not supported in this specification
(it will be specified in a future document).
See the working group draft [5] for a full explanation of these
changes.
Nikander Expires December 18, 2003 [Page 4]
Internet-Draft SEND with CGA ext June 2003
3. CGA based Inline Key Management Protocol (IKMP)
A new IPv6 extension header is used to define an Inline Key
Management Protocol (IKMP), used to create IPsec AH Security
Associations. The lifetime of such a SAs is limited to the handling
of the particular packet. That is, once the packet has been
processed, the SA is discared.
The new extension header MUST be placed before the AH header.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | RES | PAD |CC | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Modifier |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Public key .
. (variable length, with padding at the end) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following definitions:
Next Header The following IP extension header, typically AH.
Hdr Ext Len Length of the extension header, as defined in RFC2461
[1].
RES Reserved. Zero when sent and ignored when received.
PAD Number (0-7) of padding octets following the public key.
CC CGA Collision Count, as defined in [6].
Algorithm Public key algorithm used, as defined in RFC2535 [2].
Nikander Expires December 18, 2003 [Page 5]
Internet-Draft SEND with CGA ext June 2003
RESERVED Placeholder for a potential extension that would allow the
SA to be used for longer than just processing the one packet.
Timestamp Timestamp, in millisecond granularity. See the discussion
in the working group draft [5].
Modifier CGA Modifier, as defined in [6].
Public key CGA Public key, in RFC2535 [2] format. For RSA, RFC3110
[3] is used.
3.1 Processing rules for outgoing packets
In a conforming host, there can be both CGA and non-CGA addresses in
parallel. A CGA address in an address that has been generated
according to the CGA method, and is associated with a Collision
Count, Modifier, and Public key. The rules of this section apply
only when using a CGA source address.
When sending a packet using a CGA address as a source address, the
host SHOULD add the CGA extension header to the outgoing packet. If
the packet is IPsec protected, the header MUST be added in prior to
IPsec processing, so that the possible AH signature covers the
header. The header MUST be placed between the IP header and the AH
header, so that it is processed before the AH header at the receiving
end.
The PAD, CC, Algorithm, Modifier and Public Key fields must be filled
according to the CGA specification and the associated address
generation. The details are left for future work, but follow the
ideas from the CGA specification [6].
3.2 Processing rules for incoming packets
Upon encountering an CGA extension in an incoming packet, the
following processing rules apply.
The receiver forms CGA parameters from the routing prefix in the IPv6
source address in the IP header, the CC, Algorithm, Modifier and
Public Key fields in the CGA extension header, and performs the CGA
verification on the resulting CGA parameters structure. The details
are left for future work, but follow the ideas from the CGA
specification [6].
If the CGA verification fails, the packet MUST be silently dropped.
If the CGA verification succeeds, the host creates a new IPsec AH
Nikander Expires December 18, 2003 [Page 6]
Internet-Draft SEND with CGA ext June 2003
security association. The new assocation has a fixed, pre-configured
SPI, and is selected based on the SPI and the source address.
Alternatively, the CGA header could itself carry the SPI, but the
security implications of that has not been analyzed sufficiently
much. The resulting SA is defined as follows.
+------------------------------------------------------+
| Name | Direction | SPI | Proto | Dst | Source |
+------------------------------------------------------+
| CGA_In | Inbound | To be | AH | Any | From |
| | | assigned | | | the |
| | | by IANA | | | IP hdr |
+------------------------------------------------------+
The lifetime of the SA is one packet.
(Implementation note: Possibly the easiest way of implementing the
SA is to attach it as meta-data to the packet being processed.)
Nikander Expires December 18, 2003 [Page 7]
Internet-Draft SEND with CGA ext June 2003
4. Certificate based Key Management Protocol (KMP)
Using the multicast based certificate discovery mechanism specified
in the working group draft [5], it is possible to define a Key
Management Protocol that creates public key based security
associations. Such SAs could be used in the place of a CGA based SAs.
However, the details of that are left for future work.
Nikander Expires December 18, 2003 [Page 8]
Internet-Draft SEND with CGA ext June 2003
5. IPsec Extensions
5.1 The AH_RSA Algorithm
The AH_RSA algorithm specifies how AH can be used with a public key,
bound to the sender IP address. This transform introduces the use of
a new reserved SPI number and a new format for the Integrity Check
Value (ICV) field in AH.
5.1.1 Reserved SPI Number
The AH_RSA MUST be only be used with the reserved SPI number TBD <To
Be Assigned by IANA>.
5.2 AH_RSA Security Associations
Incoming security associations that specify the use of AH_RSA
transform MUST record the following additional configuration
information:
publickey Public key to verify the signature.
Outgoing security associations MUST record the following additional
information:
keypair A public-private key pair.
5.3 Processing Rules for Senders
A node sending a packet using the AH_RSA algorithm MUST construct the
packet as follows:
o The Next Header, Payload Len, and Reserved fields are set as
described in RFC 2402.
o The Security Parameters Index is set to the value specified in
Section 5.1.1.
o The packet, in the form defined for AH's coverage, is signed using
the private key in the security association, and the resulting
PCKS #1 signature is put to the Integrity Check Value field.
5.4 Processing Rules for Receivers
A packet received on a security association employing AH_RSA
transform MUST be checked as follows:
Nikander Expires December 18, 2003 [Page 9]
Internet-Draft SEND with CGA ext June 2003
o Next Header and Payload Len fields are valid as specified in RFC
2402.
o The SPI field is equal to the value defined in Section 5.1.1.
o The Digital Signature in the Integrity Check Value is verified
using the public key from the Security Association.
Packets that do not pass all the above tests MUST be silently
discarded.
Nikander Expires December 18, 2003 [Page 10]
Internet-Draft SEND with CGA ext June 2003
6. Other IPsec Extensions
6.1 Destination Agnostic Security Associations
In order to allow the same security association to be used when the
the node sends packets to different peers using the same addresses,
an extension must be provided to the RFC 2401 rules on how security
associations are identified. This change is particularly important,
for instance, when routers use the same keys and security association
to send Router Advertisements for up to number of prefixes x 2^64
hosts on an interface.
This extension is mandatory for all nodes that support the AH_RSA
algorithm. Security associations that use the SPI value specified in
Section 5.1.1 MUST be identified based on the SPI, the protocol
numbers, and the source address, but not by the destination IP
address.
Note that this extension can be supported with a very small
implementation modification if the proposed revisions of the IPsec
standards are in use [4]. More specifically, the only required
modification is to allow incoming SA selection to be based on source
address while ignoring the destination address. Currently such usage
is not defined.
6.2 ICMP Type Specific Selectors
In order to allow finer granularity of protection for various ICMPv6
messages, it is necessary to extend the security policy database and
security association selectors with the capability to distinguish
between different messages.
All nodes that support Secure Neighbor Discovery MUST be capable of
using ICMP and ICMPv6 Type field as a selector.
Note that this can be achieved in an implementation by using the port
number field to contain the ICMP type if the protocol field is ICMP.
Nikander Expires December 18, 2003 [Page 11]
Internet-Draft SEND with CGA ext June 2003
7. Other functionality
In most other respects, this proposal follows the official working
group document. No other changes are currently proposed, but they
are likely to emerge as this proposal matures.
Nikander Expires December 18, 2003 [Page 12]
Internet-Draft SEND with CGA ext June 2003
Normative References
[1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[3] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
System (DNS)", RFC 3110, May 2001.
[4] Kent, S., "IP Authentication Header",
draft-ietf-ipsec-rfc2402bis-03 (work in progress), April 2003.
[5] Arkko, J., "SEcure Neighbor Discovery (SEND)",
draft-ietf-send-ipsec-01 (work in progress), June 2003.
[6] Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-aura-cga-00 (work in progress), February 2003.
Author's Address
Pekka Nikander
Ericsson Research Nomadiclab
Jorvas 02420
Finland
EMail: Pekka.Nikander@nomadiclab.com
Nikander Expires December 18, 2003 [Page 13]
Internet-Draft SEND with CGA ext June 2003
Appendix A. IPR Considerations
The CGA method uses public keys and hashes to prove address
ownership. Several IPR claims have been made about such methods.
Nikander Expires December 18, 2003 [Page 14]
Internet-Draft SEND with CGA ext June 2003
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 implementors 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
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 assignees.
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
Nikander Expires December 18, 2003 [Page 15]
Internet-Draft SEND with CGA ext June 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Nikander Expires December 18, 2003 [Page 16]