[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                        J. Laganier
Internet-Draft                                          DoCoMo Euro-Labs
Expires: January 9, 2008                                   G. Montenegro
                                                   Microsoft Corporation
                                                                A. Kukec
                                                    University of Zagreb
                                                            July 8, 2007


       Using IKE with IPv6 Cryptographically Generated Addresses
                     draft-laganier-ike-ipv6-cga-02

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 January 9, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).











Laganier, et al.         Expires January 9, 2008                [Page 1]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


Abstract

   This document describes IKEv2 peer authentication via IPv6
   Cryptographically Generated Addresses (CGA).  This techincque have
   been proposed to solve several security issues in the absence of any
   centralized trusted security infrastructure and without any pre-
   arrangements, to provide IPSec self-evident authentication mode
   between IPv6 nodes or security gateways.


Table of Contents

   1.  Introduction and Problem Statement . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Node Configuration and Requirements  . . . . . . . . . . . . .  5
   4.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  IPsec Transport Mode with self-evident authentication  . .  7
     4.2.  IPSec Tunnel Mode with self-evident authentication . . . .  8
   5.  IKEv2 Payload usage and requirements . . . . . . . . . . . . . 11
     5.1.  Identification Payload . . . . . . . . . . . . . . . . . . 11
     5.2.  Certificate Payload  . . . . . . . . . . . . . . . . . . . 11
     5.3.  Certificate Request Payload  . . . . . . . . . . . . . . . 11
     5.4.  Authentication Payload . . . . . . . . . . . . . . . . . . 12
     5.5.  Traffic Selector Payload . . . . . . . . . . . . . . . . . 12
   6.  IKE_AUTH validation  . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  IPSec Transport Mode with self-evident authentication  . . 13
     6.2.  IPSec Tunnel Mode with self-evident authentication . . . . 14
   7.  Comparation with Better Than Nothing Security (BTNS) . . . . . 15
   8.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   10. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 18
   11. Intellectual Property Rights Considerations  . . . . . . . . . 19
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     12.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 22














Laganier, et al.         Expires January 9, 2008                [Page 2]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


1.  Introduction and Problem Statement

   This document describes how to use IKEv2 with IPv6 Cryptographically
   Generated Address (CGA).  The use of CGA provides authentication for
   IKEv2 based on the address-proof-of-ownership.  It requires only
   slight modification of IKEv2 protocol and provides self-evident
   authentication between previously unknown IPv6 nodes and/or gateways.

   CGAs have been proposed to solve several security issues in the
   absence of any centralized trusted security infrastructure and
   without any pre-arrangements, for example, securing Binding Updates
   in Mobile IPv6, securing Neighbor Discovery for IPv6, securing IPv6
   multihoming protocol - SHIM6, and securing Group Membership in
   Multicast and Anycast communications.

   Until now, the deployment of IPSec 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.  CGA provides an alternative for Security Association
   establishment that does not require using a centralized
   infrastructure or prearrangements.  This approach is similar to [4].

   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 IKEv2 daemons (e.g. racoon2, pluto, ikev2,
   etc) is another considerable advantage.

   This note is organized as follows: we will first describe related
   work and some usage scenarios for a CGA-enabled peer authentication
   within an IKEv2 exchange, then we will enumerate requirements for
   those IKEv2 payloads that need it, and finally, describe precisely
   how to perform the IKE_AUTH exchange.  Accordingly, this note
   presents an overview of how to use the Internet Key Exchange version
   2 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 IKEv2 via CGA in
   a standard manner, thus preventing subsequent conflicting
   definitions.  Currently, it has still some open aspects/issues.










Laganier, et al.         Expires January 9, 2008                [Page 3]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


2.  Terminology

   Cryptographically Generated Address (CGA): An adress which is
   generated in accordance with [2].  Any crypto address used must be
   generated as a CGA.

   CGA enabled Node: An IPv6 node that has one CGA configured as its
   IPv6 address and posseses related CGA Parameters structure, as well
   as the private key.  For such nodes we use terms initiator and
   responder.  CGA enabled Nodes are present both in the transport
   scenario and tunnel scenario.

   CGA enabled Security Gateway: An IPv6 enabled IPsec security gateway
   which applies tunnel mode CGA Security Policy (CGA SP), either in the
   net to net scenario or in the endpoint to net scenario.  It posseses
   CGA and related CGA Paramateres data structure.  We use mark GW_i for
   the initiator's CGA enabled Security Gateway and GW_r for the
   responder's CGA enabled Security Gateway.

   Self-evident authentication mode: It denotes the use of IPSec/IKEv2
   between previously unknown CGA enabled nodes and/or CGA enabled
   gateways.  The IKEv2 Security Association establishment in case of
   self-evident authentication mode of IPSec does not require any pre-
   arrangements nor trusted security infrastructure.

   CGA Security Policy (CGA SP): A CGA 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 CGA
   enabled Security Gateways, while in transit in the public internet).




















Laganier, et al.         Expires January 9, 2008                [Page 4]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


3.  Node Configuration and Requirements

   Each CGA enabled Node and CGA enabled Security Gateway MUST prove
   address ownership of its CGA.  CGA has to be generated and verified
   against CGA Parameters data structure as described in [2].  The CGA
   authentication procedure includes the following steps:

   1.  The verification of binding between the CGA and the proposed
       public key/CGA Parameters data structure.  Peer has to verify: a)
       the produced hash of the CGA Parameters data structure, b) the
       prefix of the CGA.  The lower 64 bits of the hash MUST match the
       iid of the CGA.  Also, the prefix contained in the CGA Parameters
       data structure MUST be the same as the prefix in the CGA.

   2.  The verification that the peer's private key corresponds to the
       public key from the CGA Parameters data structure.  For example,
       the responder MUST verify the challenge signed with the
       initiator's private key with the initiator's public key received
       in the CGA Parameters data structure.

   Succesfull verification denotes that the public key in the CGA
   parameters is the authentic public key used to generate CGA.  Both
   CGA enabled Nodes and CGA enabled Security Gateways use their CGA as
   IKEv2 identities.

   Thus, each CGA enabled Node and Security Gateway generate a RSA
   public (PK) - private (SK) key pair in accordance with Internet X.509
   certificate profile (rfc3280).  Usually, keys will be generated
   together with the self-signed X.509 certificate.

   The following requirements are related to tunnel mode scenarios and
   are actually open issues:

      Beside the check of the PK-CGA binding of peer GW's CGA, each CGA
      enabled Security Gateway SHOULD verify also the initiator's and
      responder's PK-CGA binding.  In that case, gateways need to
      exchange CGA Parameters related to initiator's and responder's
      CGA.  The PAD database could be used to store the initiator's/
      responder's CGA Parameters (TBD).  Those CGA Parameters could be
      exchanged in the IKE_AUTH exchange (TBD).

      Beside the address-proof-of ownership, gateways (GW_i and GW_r)
      SHOULD mutually prove themselves that they had been authorized to
      act as CGA enabled Security Gateways for the initiator's or
      responder's CGA (respectively).  This could be solved with the
      authorization certificates, eg. initiator could issue certificate
      to GW_i to allow GW_i to be its CGA enabled Security Gateway.
      However, authorization certificates SHOULD not be used for this



Laganier, et al.         Expires January 9, 2008                [Page 5]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


      purpose because of the incompliance with the IKEv2 spec and CGA
      spec.  Both specifications require use of the X.509 Certificate -
      Signature.  This issue SHOULD be rather solved with making use of
      PAD database to store additional authentication and authorization
      parameters (TBD).














































Laganier, et al.         Expires January 9, 2008                [Page 6]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


4.  Usage Scenarios

   CGA authentication within an IKEv2 exchange can be applied in several
   different usage scenarios.  The following sections describe some of
   these scenarios while emphasizing on easiness of Security Policy
   configuration.

   Self-evident authentication mode for 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 related
   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.

   While the supported IKEv2 identites are IPv4 addresses, IPv6
   addresses, FQDN, email addresses, X.500 Distinguished Name, X.500
   General Name and vendor-specific identity, the self-evident
   authentication mode of IPSec provides the possibility to identify
   with IPv6 address or FQDN.  In case of FQDN identity, the DNBS would
   provide the binding between the FQDN and the IPv6 address and then
   the CGA would provide the binding between the IPv6 address and the
   crypto material.

   In the rest of the section, we describe the following three
   application scenarios: transport mode, tunnel mode gateway to gateway
   and tunnel mode node to gateway.

4.1.  IPsec Transport Mode with self-evident authentication

   IPSec Transport Mode with the self-evident authentication secures
   end-to-end communications between any two previously unknown CGA
   enabled Nodes and thus provides any-to-any trust relationships.  For
   instance, let's assume that initiator initially wants to send a data
   packet to responder.  Transport Mode CGA SP requires protection of
   this data packet.  As no trust relationship exists between initiator
   and responder prior to this, they needs to establish a Transport Mode
   IPsec Security Association.

   [initiator]<=i=p=s=e=c==t=r=a=n=s=p=o=r=t=>[responder]




Laganier, et al.         Expires January 9, 2008                [Page 7]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


   Bootstrapping an IPsec SA between two CGA enabled Nodes is
   straightforward: the two peers merely prove ownership of their CGA's
   while performing the IKEv2 exchange, and configure negotiated IPsec
   SA's.

   A typical Transport Mode CGA SP policy should look like that:

      INBOUND:

      ::0/0[ike] -> cga_addr/128[any] udp bypass

      ::0/0[any] -> cga_addr/128[ike] udp bypass

      ::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)

4.2.  IPSec Tunnel Mode with self-evident authentication

   IPSec Tunnel Mode with self-evident authentication is used to secure
   communications between two CGA enabled nodes (initiator and
   responder), while this traffic is in transit between their gateways
   (GW_i and GW_r).

   [initiator]<---[GW_i]<=i=p=s=e=c==t=u=n=n=e=l=>[GW_r]--->[responder]

   Bootstrapping a tunnel mode IPsec SA between two CGA enabled nodes is
   not as straightforward as it is for transport mode, because (1) the
   GW_r needs to be discovered by the GW_i, and (2) both GW_i and GW_r
   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 CGA SP 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 initiator
   resides, a typical Tunnel Mode CGA SP should look like that on the
   interface of GW_i attached to the Internet:






Laganier, et al.         Expires January 9, 2008                [Page 8]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


      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

      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 IKEv2 exchange towards a per
   network prefix anycast address allocated by IANA.  Others discovery
   means are also possible, for example, DNS queries to retrieve the CGA
   enabled Security Gateway associated with a given host.  Gateway's
   authorization during the IKE_AUTH exchange in case of the self-
   evident authentication mode of IPSec imply the verification of TS_i
   and TS_r payloads (initiator's and responder's CGA) against their CGA
   parameters.  Initiator's and responder's CGA parameters are stored in
   the GW_i's and GW_r PAD (respectively) and exchanged during the
   IKE_AUTH exchange in CERT payloads (TBD).

   When a packet from initiator to responder triggers an IKEv2 exchange,
   GW_i and GW_r merely prove ownership of their CGAs.  Additionally,
   they check the ownership of CGA for the initiator and responder.  In
   the same time, while GW_i and GW_r posses initiator's and responder's
   CGA Parameters (respectively) stored in their PAD, GW_i and GW_r
   prove that they are authorized to be the initiator's and responder's
   CGA enabled Security Gateway.  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 initiator and responder's CGA require IPsec
   protection:

      initiator_CGA/128[any] -> responder_CGA/128[any] any require
      (ipsec/ah/esp/tunnel=GW_i->GW_r)



Laganier, et al.         Expires January 9, 2008                [Page 9]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


      responder_CGA/128[any] -> initiator_CGA/128[any] any require
      (ipsec/ah/esp/tunnel=GW_i->GW_r)

















































Laganier, et al.         Expires January 9, 2008               [Page 10]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


5.  IKEv2 Payload usage and requirements

   A peer implementing the self-evident authentication mode of IPSec has
   to use IKEv2 payloads in a specific manner.  The following
   subsections describe usage and requirements of some of the IKEv2
   payloads while performing IKE_AUTH exchange.

5.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 (initiator's or
   responder's CGA in the transport mode, and GW_i's or GW_r's CGA in
   the tunnel mode).  CGA is embedded within the ID payload under the
   known IKEv2 type ID_IPV6_ADDR.  CGA enabled node or gateway MAY use
   also IKEv2 ID_FQDN type (TBD).  In that case the CGA technique is a
   natural complement of the DNSSec.

5.2.  Certificate Payload

   The name of the Certificate (CERT) payload is rather misleading and
   the CERT payload is not used to transport only certificates, but also
   different authentication material/credentials.  In case of the self-
   evident authentication mode of IPSec, the CERT payload is used to
   transmit the CGA Parameters data structure.

   Each CGA enabled Node or Security gateway wanting to prove CGA
   ownership MUST send to peer its CGA and CGA Parameters used when
   generating its CGA.  CGA Parameters data structure requires the new
   type of CERT payload.  That new type of CERT payload will trigger the
   CGA verification during the IKE_AUTH exchange.  In the tunnel mode,
   beside the CGA Parameters related to their CGA, GW_i and GW_r SHOULD
   exchange initiator's and responder's CGA Parameters (TBD).

5.3.  Certificate Request Payload

   The Certificate Request (CERTREQ) Payload is used by a peer to
   request preferred certificates to its correspondent.  A preference is
   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.  The related
   CERTREQ payload MUST be set to the same type as the CERT payload.
   Thus, the same as for the CERT payload, we need the new type of the
   CERTREQ payload.





Laganier, et al.         Expires January 9, 2008               [Page 11]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


5.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 in the CGA Parameters data
   structure.  Currently specified digital signature algorithms includes
   RSA and DSA, but this scheme could be used with any public key
   cryptographic algorithm.

5.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 the
   self-evident authentication mode of IPSec, those flows will fly
   between two CGA's.  Both in the transport and tunnel mode, TS
   payloads will contain initiator's and responder's CGA.  Hence we
   require that the TS payloads used contains CGAs.  This imply that the
   TS Type is set to TS_IPV6_ADDR_RANGE.  In the transport mode, both
   the ID payload and the TS payloads contain initiator's and
   responder's CGAs.  In the tunnel mode, ID payload contains gateways'
   CGAs, while TS payloads contain initiator's and responder's CGA.
   Those CGA's from TS payloads will subsequently need to be validated
   against CGA Parameters exchanged in the CERT payload of new type.


























Laganier, et al.         Expires January 9, 2008               [Page 12]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


6.  IKE_AUTH 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 gateways) MUST verify CGA ownership.  CGA-aware
   IKEv2 implementation should thus be modified to handle CGA
   verification, which is very similar to how they currently handle
   self-signed certificates.  The implementation MUST verify that the
   public key contained in the received CGA Parameters generate the
   address used as IKEv2 identity.

6.1.  IPSec Transport Mode with self-evident authentication

   Validation of the IKE_AUTH only requires CGA-PK binding verification.
   The initial IKEv2 exchanges will be as follows:

       IKE_SA_INIT exchange:

       1. initiator -> responder:  HDR, SAi1, KEi, Ni
       2. responder -> initiator:  HDR, SAr1, KEr, Nr, CERTREQ=CGA_type

       IKE_AUTH exchange:

       3. initiator -> responder: HDR,
                                  SK {IDi=CGA_i,
                                      CERT=CGA_Parameters_i,
                                      CERTREQ=CGA_type,
                                      AUTH=dig_sig(CGA_Parameters_i_PK),
                                      SAi2,
                                      TSi=CGA_i, TSr=CGA_r}
       4. responder -> initiator: HDR,
                                  SK {IDr=CGA_r,
                                      CERT=CGA_Parameters_r,
                                      AUTH=dig_sig(CGA_Paramters_r_PK),
                                      SAr2,
                                      TSi=CGA_i, TSr=CGA_r}






Laganier, et al.         Expires January 9, 2008               [Page 13]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


6.2.  IPSec Tunnel Mode with self-evident authentication

   Tunnel mode requires the following:

      verification of binding between received gateway's CGA Parameters
      and its CGA/IKEv2 identity (MUST),

      verification of binding between received initiator's and
      responder's CGA in TS payloads (TBD),

      verification that the GW_i/GW_r is authorized to act as
      initiator's/responder's CGA gateway (TBD).

   Initial IKEv2 exchanges will be as follows (TBD):

       IKE_SA_INIT exchange:

       1. GW_i -> GW_r: HDR, SAi1, KEi, Ni
       2. GW_r -> GW_i: HDR, SAr1, KEr, Nr, CERTREQ=CGA_type

       IKE_AUTH exchange:

       3. GW_i -> GW_r: HDR, SK {IDi=CGA_GW_i,
                                 CERT=CGA_Parameters_GW_i,
                                 CERT=CGA_Parameters_i,
                                 CERTREQ=CGA_type,
                                 AUTH=dig_sig(CGA_Parameters_GW_i_PK),
                                 SAi2,
                                 TSi=CGA_i, TSr=CGA_r}
       4. GW_r -> GW_i: HDR, SK {IDr=CGA_GW_r,
                                 CERT=CGA_Parameters_GW_r,
                                 CERT=CGA_Parameters_r,
                                 AUTH=dig_sig(CGA_Paramters_GW_r_PK),
                                 SAr2,
                                 TSi=CGA_i, TSr=CGA_r}
















Laganier, et al.         Expires January 9, 2008               [Page 14]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


7.  Comparation with Better Than Nothing Security (BTNS)

   Differences between the IPSec self-evident verification mode and the
   BTNS are listed along the following lines.

   The IPSec self-evident verification mode, as a slight modification of
   the regular IKEv2, does not raise new security concerns to IPSec/
   IKEv2.  The BTNS lacks the authentication, and therefore raises some
   security concerns that are described below.

   Due to the lack of authentication, BTNS does not protect the key
   exchange itself.  Contrary to the regular IKEv2, first IKEv2 exhcange
   (IKE_SA_INIT) is not integrity protected.  This opens the possibility
   for the masquerader, MITM and DOS attacks.  An attacker can easily
   masquerade as a legitimate client and acquire a sensitive
   authentication information.  It can also establish two different
   Security Associations between endpoints and thus perform the MITM
   attack.  As described in [3] BTNS detectes mentioned attacks only
   after the session establishment, which can lead to the CPU exhaustion
   during the initial IKEv2 exchanges.

   The lack of authentication in BTNS constraints the IPSec usage only
   to services that use the anonymous access.

   While BTNS does not require the deployment of identities, the IPSec
   self-evident verification mode requires the use of either IPv6
   addresses or FQDNs as IKEv2 identities.  The reduced number of IKEv2
   identites does not constrain the IPSec deployment, if we take into
   account two assumptions: a) it is reasonable to expext that in IPv6
   (even with) adresses would be stable, b) it is also reasonable to
   expect that DNS mappings are up-to-date.




















Laganier, et al.         Expires January 9, 2008               [Page 15]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


8.  Conclusion

   This note presents an overview of how IKEv2 and CGA can be combined
   to achieve self-evident authentication mode of 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, et al.         Expires January 9, 2008               [Page 16]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


9.  Security Considerations

   This document discusses possible use of IKEv2 as a means to prove CGA
   ownership and exchange keys to bootstrap IPsec SA's.  Because IKEv2
   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 self-evident authentication mode of IPsec might be subject to
   Denial of Service (DoS) attacks.  There are two types of such
   attacks: fake/malicious initiator and fake/malicious destination.

   A rogue CGA enabled security gateway may attack from 'outside',
   trying to exhaust the gateway's resources by attempting to establish
   as many IPsec tunnels as it can towards machine of the protected
   network prefix.  This is done by initiating many IKEv2 exchanges.
   The fake initiator typically sends a lot of spoofed packets with
   random source addresses.  This does not cause much harm as the IKEv2
   exchange will not progress any further.  On the other hand, the
   malicious initiator sends regular packets to progress into the IKEv2
   exchange.  The process of mutual gateway's authorization (which is
   still marked as TBD) could solve this issue.





















Laganier, et al.         Expires January 9, 2008               [Page 17]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


10.  Open Issues

   This document introduce a new CERT/CERTREQ payload type (CGA
   Parameters) which, among other, triggers the CGA self-evident
   authentication mode within IPSec/IKEv2.














































Laganier, et al.         Expires January 9, 2008               [Page 18]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


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, et al.         Expires January 9, 2008               [Page 19]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


12.  References

12.1.  Normative References

   [1]  Kaufman, C., "The Internet Key Exchange version 2 (IKEv2)",
        RFC 4306, December 2005.

   [2]  Aura, T., "Cryptographically Generated Addresses (CGA)",
        RFC 3972, March 2005.

   [3]  Touch, J., Black, D., and Y. Wang, "Problem and Applicability
        Statement for Better Than Nothing Security (BTNS)",
        draft-ietf-btns-prob-and-applic-05 (work in progress),
        February 2007.

12.2.  Informative References

   [4]  Castelluccia, C., Montenegro, G., Laganier, J., and C. Neumann,
        "Hindering Eavsdropping via IPv6 Opportunistic Encryption",
        LNCS ESORICS 2004, September 2004.































Laganier, et al.         Expires January 9, 2008               [Page 20]


Internet-Draft          Using IKE with IPv6 CGAs               July 2007


Authors' Addresses

   Julien Laganier
   DoCoMo Euro-Labs
   Landsbergerstrasse 312
   D-80687 Muenchen
   Germany

   Email: julien.IETF@laposte.net


   Gabriel Montenegro
   Microsoft Corporation
   One Microsoft Way
   Redmonds, WA 98052
   USA

   Email: gabriel_montenegro_2000@yahoo.com


   Ana Kukec
   University of Zagreb
   Unska bb
   Zagreb
   Croatia

   Email: anchie@tel.fer.hr
























Laganier, et al.         Expires January 9, 2008               [Page 21]


Internet-Draft          Using IKE with IPv6 CGAs               July 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).





Laganier, et al.         Expires January 9, 2008               [Page 22]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/