Network Working Group J. Laganier
Internet-Draft ENS Lyon / Sun Microsystems, Inc.
Expires: December 29, 2003 G. Montenegro
Sun Microsystems, Inc.
June 30, 2003
Using IKE with IPv6 Cryptographically Generated Address
draft-laganier-ike-ipv6-cga-01
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 29, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes IKE peer authentication via IPv6
Cryptographically Generated Addresses (CGA). This technique can be
used to provide 'Opportunistic IPsec' between IPv6 nodes or security
gateways. These CGA's have been proposed to solve several security
issues in the absence of any centralized trusted security
infrastructure.
Laganier & Montenegro Expires December 29, 2003 [Page 1]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . . 3
2. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Node Configuration and Requirements . . . . . . . . . . . . . 6
5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Transport Mode Opportunistic IPsec . . . . . . . . . . . . . . 8
5.2 Tunnel Mode Opportunistic IPsec . . . . . . . . . . . . . . . 9
6. ISAKMP Payload usage and requirements . . . . . . . . . . . . 11
6.1 Identification Payload . . . . . . . . . . . . . . . . . . . . 11
6.2 Certificate Payload . . . . . . . . . . . . . . . . . . . . . 11
6.3 Certificate Request Payload . . . . . . . . . . . . . . . . . 11
6.4 Authentication Payload . . . . . . . . . . . . . . . . . . . . 12
6.5 Traffic Selector Payload . . . . . . . . . . . . . . . . . . . 12
7. IKE_AUTH and CREATE_CHILD_SA validation . . . . . . . . . . . 13
7.1 Opportunistic Transport Mode . . . . . . . . . . . . . . . . . 13
7.2 Opportunistic Tunnel Mode . . . . . . . . . . . . . . . . . . 13
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Intellectual Property Rights Considerations . . . . . . . . . 17
Normative References . . . . . . . . . . . . . . . . . . . . . 18
Informative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 21
Laganier & Montenegro Expires December 29, 2003 [Page 2]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
1. Introduction and Problem Statement
This document describes how to use IKE with IPv6 Cryptographically
Generated Address (CGA). This technique only requires slight
modifications and can be used by one or both peers to achieve
'Opportunistic IPsec' ([4]).
One use of CGA is address proof-of-ownership, but it can also be used
with authorization certificates (e.g. SPKI, Keynote2) to enable a
flexible authorization framework. CGA's have been proposed to solve
several security issues in the absence of any centralized trusted
security infrastructure, for example, securing Binding Updates in
Mobile IPv6, securing Neighbor Discovery for IPv6, and securing Group
Membership in Multicast and Anycast communications.
Until now, Opportunistic IPsec deployment has been severely limited
because it constrains IP nodes to have either a pre-shared key or a
common trusted root (e.g., a PKI infrastructure). Thus, the lack of
a global, Internet-wide, trusted infrastructure has precluded a
straightforward application of IPsec between any two previously
unknown nodes. The impossibility of always having the choice of
obtaining a security association by leveraging a centralized
infrastructure has led to this type of cryptographic techniques
commonly known as CGA or SUCV to be applied to IPsec.
This note is organized as follows: we will first describe related
work and some usage scenarios for a CGA-enabled peer authentication
within an IKE exchange, then we will enumerate requirements for those
ISAKMP payloads that need it, and finally, describe precisely how to
validate the IKE_AUTH_SA and CREATE_CHILD_SA steps of such an IKE
exchange.
Laganier & Montenegro Expires December 29, 2003 [Page 3]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
2. Related work
CGA usage has lacked generality as it has been applied either within
specific frameworks like Mobile IP ([5], [6]) or using its own custom
protocol, Statistically Unique and Cryptographically Verifiable
protocol (sucvP) [5]. Lately, a proposal using Just Fast Keying
(JFK) has been put forth ([9]). Nevertheless, we believe that a
full-blown key exchange protocol is redundant. Moreover, because the
design, implementation and debugging of a new security protocol is
especially costly and error-prone, we think that it is not worth
"reinventing the wheel". From the point of view of implementation
effort, the fact that this approach only requires the addition of
stand-alone CGA validation routines into existing IKE daemons (e.g.
racoon, isakmpd, pluto, etc) is another considerable advantage.
Accordingly, this note presents an overview of how to use the
Internet Key Exchange protocol [1] while one or both peers
authenticate themselves via CGA proof-of-ownership. This document
details the slight modifications needed. Additionally, it aims at
capturing the current thinking about how to achieve proof-of-
ownership in IKE via CGA in a standard manner, thus preventing
subsequent conflicting definitions.
Laganier & Montenegro Expires December 29, 2003 [Page 4]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
3. Terminology
Cryptographically Generated Address (CGA): An adress which is
obtained using cryptographic material as input parameter to a hash
function.
Crypto-Based Identifier (CBID): An identifier which is obtained using
cryptographic material as input parameter to a hash function.
CGA enabled Node: An IPv6 node that has one CGA configured as its
IPv6 address.
Opportunistic IPsec (OIPsec): Opportunistic IPsec denotes the use of
the IPsec family of protocols between previously unknown nodes
implementing an Opportunistic Security Policy. This includes running
IKE between those peers to establish an IPsec Security Association
(ESP and/or AH in either Transport or Tunnel Mode).
Opportunistic Security Gateway (OSGW): An opportunistic gateway is an
IPsec security gateway which applies a tunnel mode Opportunistic
Security Policy (OSP) to traffic originating from or sinking at its
"local network". It has a CBID instead of a CGA, and holds SPKI
authorization certificates issued by the CGA's it protects with
OIPsec.
Opportunistic Security Policy (OSP): An Opportunistic Security Policy
is a Security Policy that specifies that traffic towards any outbound
destination (i.e., ::0/0) SHOULD be protected by IPsec, either
transport mode or tunnel mode (transport mode for securing end-to-end
traffic between two nodes and tunnel mode for securing traffic
between two OSGW's, while in transit in the public internet).
Laganier & Montenegro Expires December 29, 2003 [Page 5]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
4. Node Configuration and Requirements
Each node needs to prove address ownership of their CGA. Similarly,
OSGW's only need to prove identifier ownership of their CBID. Thus,
they generates a public-private key pair, PK and SK, respectively.
The nodes then use PK to obtain and configure a CGA and the OSGW's a
CBID as specified in [5]:
CBID = SHA1_128 ( PK )
CGA = NetworkPrefix | SHA1_64 ( PK )
Where PK can be a PK certificate (see below)
Those nodes that want to prove that they own their CGA should use it
as their so-called IKE "peer" address while sending IKE packets.
OSGW's can use any of their addresses, but they need to have an SPKI
authorization certificate issued on their behalf by each CGA holder:
CGA_1 => CBID : OSGW
CGA_2 => CBID : OSGW
(...)
CGA_n => CBID : OSGW
Meaning that each CGA_i (0<i<n+1) authorize CBID to act as an
OSGW.
For practical reasons, we choose to define CBID and CGA as the hash
of the node's X509 certificates, as they contains validity dates and
other data that may be useful. In order to limit the validity scope
of the PK<->CGA mapping to the network prefix in which the CGA
resides, the certificate is concatenated with this network prefix
before hashing, as per [6]. This alleviate the problem of pre-
computation attacks on the CGA key-space (2^62). Thus, one is not
able to re-use the results of a previous brute-force search attacks
on CGA.
CBID = SHA1_128 ( X509{PK} )
Laganier & Montenegro Expires December 29, 2003 [Page 6]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
CGA = NetworkPrefix | SHA1_64 ( X509Cert{PK} | NetworkPrefix)
Notice that the CBID generated from a certificate is indeed very
similar to the FullID proposal [7]. Another technique to generate
CGA's with an increased security level of 112 bits (instead of the 62
bits provided in the IID) has been described for SEND purposes [8].
Laganier & Montenegro Expires December 29, 2003 [Page 7]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
5. Usage Scenarios
CGA authentication within an IKE exchange can be applied in several
different usage scenarios. The following sections describe some of
these scenarios while emphasizing on easiness of Opportunistic
Security Policy configuration.
Opportunistic IPsec bootstraps an IPsec Security Association between
two previously unknown nodes. Some schemes have been proposed to
achieve this goal: FreeS/WAN Opportunistic IPsec uses the standard
IKE protocol and DNS queries to retrieve IKE peers' public keys.
While these schemes certainly allow to bootstrap such an SA, we argue
that it is not convenient to rely on upper layer infrastructure
(e.g., DNS) to secure the network layer. This causes cyclic
dependencies that ends up in a chicken-and-egg problem: DNS is
carried over {TCP|UDP}/IP and a consistent Opportunistic security
policy should require that this traffic be protected as well, thus
requiring Opportunistic negotiation to secure needed KEY RR lookups.
On the other hand, a CGA-based scheme achieves true independence
because the security gateways can discover each other and verify
authorization by relying solely on IP infrastructure. We propose one
CGA Opportunistic IPsec scheme per IPsec mode (transport and tunnel).
5.1 Transport Mode Opportunistic IPsec
Transport Mode Opportunistic IPsec secures end-to-end communications
between any two previously unknown CGA-enabled nodes implementing an
OSP. For instance, let's assume that Alice initially wants to send a
data packet to Bob. Transport Mode OSP requires protection of this
data packet. As no trust relationship exists between Alice and Bob
prior to this, they needs to establish a Transport Mode IPsec
Security Association.
[Alice]<=i=p=s=e=c==t=r=a=n=s=p=o=r=t=>[Bob]
Bootstrapping an IPsec SA between two CGA-enabled nodes is
straightforward: the two peers merely prove ownership of their CGA's
while performing the IKE exchange, and configure negotiated IPsec
SA's.
A typical Transport Mode OSP policy should look like that:
INBOUND:
::0/0[ike] -> cga_addr/128[any] udp bypass
::0/0[any] -> cga_addr/128[ike] udp bypass
Laganier & Montenegro Expires December 29, 2003 [Page 8]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
::0/0[any] -> cga_addr/128[any] any require (ipsec/ah/esp/
transport)
OUTBOUND:
cga_addr/128[any] -> ::0/0[ike] udp bypass
cga_addr/128[ike] -> ::0/0[any] udp bypass
cga_addr/128[any] -> ::0/0[any] any require (ipsec/ah/esp/
transport)
5.2 Tunnel Mode Opportunistic IPsec
This section uses the model and mechanism described in ([9]) applied
with IKE. Tunnel Mode Opportunistic IPsec is used to secure
communications between two CGA-enabled nodes (Alice and Bob), while
this traffic is in transit between Alice and Bob's OSGW's (GW_i
denotes the IKE initiator and GW_r the responder).
[Alice]<---[GW_i]<=i=p=s=e=c==t=u=n=n=e=l=>[GW_r]--->[Bob]
Bootstrapping a tunnel mode IPsec SA between two CGA-enabled nodes is
not as straightforward as it is for transport mode, because (1) the
responder OSGW GW_r needs to be discovered by the initiator OSGW
GW_i, and (2) both initiator and responder OSGW need to be authorized
by the source and destination CGA's respectively of the data packet
that initially triggered this exchange. Thus, a Tunnel Mode OSP
always contains an entry with the unspecified IPv6 address (i.e.,
::0) as a placeholder for both tunnel endpoints (local and remote).
If we denote by NetworkPrefix/pflen the network prefix and associated
length where Alice resides, a typical Tunnel Mode OSP should look
like that on the interface of GW_i attached to the Internet:
INBOUND:
::0/0[ike] -> GW_i/128[any] udp bypass
::0/0[any] -> GW_i/128[ike] udp bypass
::0/0[any] -> NetworkPrefix/pflen[any] any require (ipsec/ah/esp/
tunnel=::0->::0)
OUTBOUND:
GW_i/128[any] -> ::0/0[ike] udp bypass
Laganier & Montenegro Expires December 29, 2003 [Page 9]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
GW_i/128[ike] -> ::0/0[any] udp bypass
NetworkPrefix/pflen[any] -> ::0/0[any] any require (ipsec/ah/esp/
tunnel=::0->::0)
GW_i can discover GW_r by initiating the IKE exchange towards a per
network prefix anycast address allocated by IANA. Others discovery
means are also possible, like those described in [4] that makes use
of DNS queries to retrieve the OSGW associated with a given host.
OSGW authorization imply the verification of authorization (a.k.a.
delegation) certificates with the TS_i and TS_r payloads. Each GW
holds a Crypto-Based Identifier (CBID) and each node that want its
traffic to be protected by this gateway uses a CGA. The gateway
holds one SPKI authorization certificate per node it protects. For
instance, Alice should provide its OSGW GW_i with an authorization
certificate issued by her CGA authorizing the CBID of GW_i to act as
an OSGW:
Alice_CGA =>GW_i_CBID : OSGW
Bob should similarly provide its OSGW GW_r with a certificate issued
by his CGA authorizing the CBID of GW_r to to act as an OSGW:
Bob_CGA =>GW_r_CBID : OSGW
When a packet from Alice to Bob triggers an IKE exchange, the two
OSGW's GW_i and GW_r merely prove ownership of their CBID's and
exchange authorization certificates issued by Alice and Bob's CGAs
authorizing their respective OSGW's to act as such. Following that,
they negotiate and configure a pair of bidirectional SA's between the
two gateways:
GW_i -> GW_r spi=0x... ipsec tunnel ah/esp keys=...
GW_i -> GW_r spi=0x... ipsec tunnel ah/esp keys=...
And they finally add two news SPD entries specifying that subsequent
communications between Alice and Bob's CGA's require IPsec
protection:
Alice_CGA/128[any] -> Bob_CGA/128[any] any require (ipsec/ah/esp/
tunnel=GW_i->GW_r)
Bob_CGA/128[any] -> Alice_CGA/128[any] any require (ipsec/ah/esp/
tunnel=GW_i->GW_r)
Laganier & Montenegro Expires December 29, 2003 [Page 10]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
6. ISAKMP Payload usage and requirements
A peer implementing OIPsec has to use ISAKMP payloads in a specific
manner. The following subsections describe usage and requirements of
some of the ISAKMP payloads while performing IKE_AUTH and
CREATE_CHILD_SA exchanges.
6.1 Identification Payload
The Identification (ID) Payload of IKE contains the name of the
entity to be authenticated with the Authentication (AUTH) Payload.
When using CGA, the name of the node is its CGA. Though CGA are IPv6
Addresses as well, a peer embedding its CGA within the ID payload
under the type ID_IPV6_ADDR would not trigger any verification of the
PK-CGA binding on the other side. Hence, we believe that a new ID
type is needed to explicitly state the cryptographic nature of a CGA
and require verification of the binding. Thus, a peer wanting to
prove CGA ownership MUST use an ID payload of type ID_IPV6_CGADDR
containing its CGA. The value of type ID_IPV6_CGADDR is initially
assigned out of the range 249-255 reserved for "private use amongst
cooperating systems", as per [2]. If justified, a subsequent, more
official assignment will imply IANA involvement. As per CGA, CBID
might require a new ID type as well. This is however very similar to
the already proposed FullID type [7].
6.2 Certificate Payload
The Certificate (CERT) Payload provide a means to transport
certificates within IKE packets. When performing CGA ownership
exchange, certificates should be used to transmit to the
correspondent the public key used to generate the CGA. When
performing a tunnel mode CREATE_CHILD_SA exchange, authorization
certificates issued by the data packet source and destination CGA's
should be exchanged. Though several types of certificates are
specified in [1], we only use those that contains either a public key
for CGA proof-of-ownership (i.e., PKCS7_WRAPP_X509_CERT, PGP_CERT,
DNS_SIGNED_KEY, X509_CERT_SIGNATURE and SPKI_CERT) or an
authorization certificates (i.e., SPKI_CERT). A peer wanting to
prove CGA ownership MUST send a CERT payload that contains the public
key used when generating its CGA. An OSGW's wanting to prove that it
is authorized to act as an OSGW for a given CGA MUST send a CERT
payload containing a SPKI authorization certificates issued by this
CGA.
6.3 Certificate Request Payload
The Certificate Request (CERTREQ) Payload is used by a peer to
request preferred certificates to its correspondent. A preference is
Laganier & Montenegro Expires December 29, 2003 [Page 11]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
the type of certificate requested as well as an acceptable
certificate authority for this type. A peer can include multiples
preferences using several CERTREQ payload. For CGA, certificates
used would usually be self-signed, though this does not preclude one
to generate its CGA using a CA-signed certificate.
6.4 Authentication Payload
The Authentication (AUTH) Payload contains data used to authenticate
the entity named in the ID payload (i.e., the CGA owner). Since CGA
are generated using public key cryptography, the AUTH payload has to
contain a digital signature of the message computed using the public
key contained in the CERT payload. Currently specified digital
signature algorithms includes RSA and DSA, but this scheme could be
used with any public key cryptographic algorithm.
6.5 Traffic Selector Payload
The Traffic Selector (TS) Payload contains headers used to identify
IP packet flows which need IPsec processing. In the case of CGA
OIPsec, those flows will fly between two CGA's. Hence we require
that the TS payloads used contains CGA's. This imply that the TS
Type is set to TS_IPV6_ADDR. Those CGA's will subsequently need to
be validated against X509 and possibly SPKI certificates contained in
the CERT payloads exchanged.
Laganier & Montenegro Expires December 29, 2003 [Page 12]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
7. IKE_AUTH and CREATE_CHILD_SA validation
[1] does not mandate that two peers exchanging keys use the same
means of authenticating themselves. Available means of
authentication are Digital Signatures, Public Key Encryption and Pre-
shared Secret. It is explicitly stated that end-points are not
required to use the same means of authenticating themselves. One
could use pre-shared secret, while the other could use a digital
signature. This note does not conflict with that, allowing one or
both entities to prove CGA ownership, thus allowing one to possibly
use another means of authenticating itself.
CGA-aware IKE peers wanting to exchange traffic with CGA enabled
nodes (e.g. nodes or OSGW's) MUST verify CGA ownership. CGA-aware
IKE implementation should thus be modified to handle CGA
verification, which is very similar to how they currently handle
self-signed certificates. Apart from verifying the self-signed
certificate, the implementation MUST verify that the public key
contained in the certificate (or the certificate itself) generate the
address used in the identity payload as previously detailed
(ID_IPV6_CGA == SHA1(X509Cert{PK} | NetworkPrefix).
7.1 Opportunistic Transport Mode
Validation of the IKE_SA_AUTH only requires CGA-PK binding
verification. Because the IKE peers that just prove CGA ownership
will also be the endpoints of any subsequently created transport mode
CHILD_SA, validation of future CREATE_CHILD_SA requests will
obviously not require additional verification since the endpoints
CGA's are already verified.
7.2 Opportunistic Tunnel Mode
Tunnel Mode requires that an OSGW verify the PK-CBID binding of its
correspondent OSGW (instead of PK-CGA), and the PK-CGA binding of the
source and destination CGA's of the data packet that initially
triggered this exchange. Those CGA's are embedded within the TS_i
and TS_r payloads. Then the two OSGW's mutually prove themselves
that they add been authorized to act as OSGW's for the traffic
implied by TS_i and TS_r.
o The responder verifies that it has an SPKI authorization
certificate issued by the destination CGA embedded in the TS_r
payload, and vice versa for the initiator.
o The responder verify that it received a CERT payload containing
a valid SPKI authorization certificate issued by the CGA embedded
within the TS_i payload, and vice versa for the initiator.
Laganier & Montenegro Expires December 29, 2003 [Page 13]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
8. Conclusion
This note presents an overview of how IKE and CGA can be combined to
achieve Opportunistic IPsec. The CGA technique is sufficiently well
understood and can use widely deployed and implemented mechanisms.
This proposal works in the absence of any previously established
direct or indirect (via a broker, AAA roaming operator or trusted
third party) security relationship. Because of this, these methods
are a very practical and deployable means of using IPsec between
previously unknown peers.
Laganier & Montenegro Expires December 29, 2003 [Page 14]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
9. Security Considerations
This document discusses possible use of IKE as a means to prove CGA
ownership and exchange keys to bootstrap IPsec SA's. Because IKE has
already been specified and this technique only slightly modifies it,
we believe that this should not raise other security concerns that
those incurred by CGA proof-of-ownership. Though the cryptographic
algorithm used are the same, CGA proof-of-ownership is very different
in nature to authentication. One must be especially careful when
establishing the security policy, as this technique allows nodes that
use their own IPv6 CGA to be successfully authenticated as their
"owner". This is similar in essence to IKE used with self-signed
certificates, with the additional consideration that CGA binds the
address to the public key. A CGA may be considered as a verifiable
self-generated address.
The Opportunistic IPsec application of this scheme might be subject
to Denial of Service (DoS) attacks. There is two types of such
attacks: fake/malicious initiator and fake/malicious destination.
A rogue opportunistic security gateway may attack from 'outside',
trying to exhaust the gateway's resources by attempting to establish
as many opportunistic IPsec tunnels as it can towards machine of the
protected network prefix. This is done by initiating many IKE
exchanges. The fake initiator typically sends a lot of spoofed
packets with random source addresses. This does not cause much harm
as the IKE exchange will not progress any further. On the other
hand, the malicious initiator sends regular packets to progress into
the IKE exchange. Fortunately, as the gateway will refuse an
exchange that is not about protecting a node for which it had a SPKI
delegation certificate, the attacker need to know which protected
node to attacks to succeed in its attack. Solutions are either to
perform a brute-force 'search' on a possible destination CGA while
negotiating the CHILD-SA, but then the attacker is committed to
complete an IKE exchange per attacked address. This might eventually
lead to a detection of the attack.
Laganier & Montenegro Expires December 29, 2003 [Page 15]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
10. Open Issues
This document introduce a new ID payload type, ID_IPV6_CGADDR.
However, it is not yet clear what is the most appropriate means of
requiring peers to verify the PK-CGA binding. Other means are
possible. In particular, the revised identity proposal [7] seems to
fulfill the requirements for CGA's and CBID's proof-of-ownership.
Laganier & Montenegro Expires December 29, 2003 [Page 16]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
11. Intellectual Property Rights Considerations
The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed 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.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Laganier & Montenegro Expires December 29, 2003 [Page 17]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
Normative References
[1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[2] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
[3] Maughan, D., Schneider, M., Schertler, M. and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
Laganier & Montenegro Expires December 29, 2003 [Page 18]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
Informative References
[4] Richardson, M. and H. Redelmeier, "Opportunistic Encryption
using The Internet Key Exchange (IKE)", draft-richardson-ipsec-
opportunistic-11.txt (work in progress), January 2003.
[5] Montenegro, G. and C. Castelluccia, "Statistically Unique and
Cryptographically Verifiable (SUCV) Identifiers and
Addresses.", NDSS 2002, February 2002.
[6] Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of
Mobile IPv6 Binding Updates and Acknowledgments", draft-roe-
mobileip-updateauth-02 (work in progress), February 2002.
[7] Hoffman, P., Aura, T., O'Shea, G. and J. Arkko, "Revised Use of
Identity in Successors to IKE", draft-ietf-ipsec-revised-
identity-00 (work in progress), April 2002.
[8] Aura, T., "Cryptographically Generated Addresses (CGA)", draft-
aura-cga-00 (work in progress), February 2003.
[9] Castelluccia, C. and G. Montenegro, "IPv6 Opportunistic
Encryption", INRIA Research Report RR-4568, October 2002.
[10] Kaufmann, C., "Internet Key Exchange version 2", draft-ietf-
ipsec-ikev2 (work in progress), 2003.
[11] Castelluccia, C. and G. Montenegro, "Securing Group Management
in IPv6 with Cryptographically Generated Addresses", IEEE
ISCC 2003, July 2003.
Authors' Addresses
Julien Laganier
ENS Lyon / Sun Microsystems, Inc.
180, avenue de l'Europe
38334 Saint Ismier CEDEX
France
EMail: julien.laganier@sun.com
Laganier & Montenegro Expires December 29, 2003 [Page 19]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
Gabriel Montenegro
Sun Microsystems, Inc.
180, avenue de l'Europe
38334 Saint Ismier CEDEX
France
EMail: gab@sun.com
Laganier & Montenegro Expires December 29, 2003 [Page 20]
Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003
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 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Laganier & Montenegro Expires December 29, 2003 [Page 21]