Subject: [CGA-EXT] Cga and Send extensIons (CSI) bof requested

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 30 Sep 2007 17:09:25 +0200

Hi all,

We have requested a slot for Vancouver for a bof on Cga and Send  
extensIons.

The proposed charter is the following:

Comments are welcome, and are preferred in the cga-ext ml

Regards, marcelo

Proposed charter for Cga & Send extensIons (CSI) BOF

The Secure Neighbor Discovery (SEND) protocol defined by RFC 3971
provides security mechanisms protecting different functions of the
Neighbor Discovery (ND) protocol defined by RFC 2461.  This includes
address resolution (discovering link layer address of another node
attached to the link), router discovery (discovering routers attached
to the link), and neighbor unreachability detection (detecting that a
node attached to the link is no longer reachable).  SEND protection of
address resolution and neighbor unreachability detection functions
relies on IPv6 address proof-of-ownership and message integrity
protection provided respectively via Cryptographically Generated
Addresses (CGAs) and RSA Digital Signatures.  However, the current
SEND specification lacks support for ND Proxies defined by RFC 3775
and RFC 4389.

CGAs are defined in RFC 3972, and are extended with a CGA extension
format defined in RFC 4581, and a support for multiple hash functions
defined in the to-be-RFC draft-bagnulo-multiple-hash-cga-03.txt.
While CGAs were originally defined for the SEND protocol, they have
proved to be a useful security tool in other environments too, and its
usage has been proposed to secure other protocols such as the Shim6
multihoming protocol and the Mobile IPv6 protocol.  As CGAs become
more widely used for various purposes, it is desirable to define
extensions that would support such new usages.

The objective of this working group is to define extensions related to
both to the SEND protocol and to CGAs.  The following are charter items
for the working group:

- Specify standards-track SEND Extensions to support Neighbor
   Discovery Proxies:  SEND protocol as currently defined in RFC 3971
   lacks of support for ND Proxies defined in RFC 3775 and RFC 4389.
   Extensions to the SEND protocol will be defined in order to provide
   equivalent SEND security capabilities to ND Proxies.

- Specify as required standards-track extensions to IKE and IPsec
   SPD and PAD to support creation of IPSec SAs authenticated via CGA
   public-private key pairs of their endpoints.  Because of their
   cryptographic nature, CGAs are inherently bound to the
   public-private key pair that was used for their generation.  This is
   used in existent protocols for proving address ownership.  However,
   it is also possible to use the CGA cryptographic material held by
   two peers to create between them a security association which is
   bound to that material.  The key benefit of such an approach is that
   the resulting security association can be cryptographically bound
   to the IP address of the endpoints without exclusive recourse to
   certificates and public key infrastructure.

- Develop an informational document analysing different approaches to
   the use of the DHCP protocol to assign CGAs, and making
   recommandations on which are the best suited.  The analysis will be
   provided as an input to the DHC working group where the actual DHCP
   extensions required to implemented the recommended approaches will
   be defined.

- Specify a standards-track CGA extension to support multiple public
   key algorithms. As currently defined CGAs can only use RSA keys in
   the CGA Parameter Data Structure, and thus cannot be generated using
   other public key algorithms (e.g. Elliptic Curve Cryptography --
   ECC). The main motivation for this work is that RSA keys are not
   well suited for environments with resource restrictions (CPU,  
storage,
   power) such as the ones considered by the 6lowpan working group. ECC
   is much well suited for such environments and the lack of support  
of ECC
   in CGAs and SeND is a deployment blocker in these environments.

- Specify standard-track extensions to RFC 4620 (IPv6 Node Information
   Queries) to support CGA-based authentication of the information
   provided. RFC4620 describes a protocol for asking an IPV6 node to  
supply
   some network information. On this extension, by the use of CGAs,
   protection against spoofing attacks and packet authentication  
mechanisms
   are provided.

- Definition of X.509 Extended Key Usage for SeND. SeND utilizes X.509v3
   certificates for performing router authorization.  It uses the X.509
   extension for IP addresses to verify whether the router is authorized
   to advertise the mentioned IP addresses.  Since the IP addresses
   extension does not explicitly mention what functions the node can
   perform for the IP addresses it becomes impossible to know the reason
   for which the certificate was allowed.  In order to facilitate  
issuance
   of certificates for specific functions, we need to encode the  
functions
   permitted for the certificate into the certificate itself.

- Update Cryptographically Generated Addresses (CGA) specification
   (i.e. RFC3972) based on the existent experience and publish as
   draft standard.

- Update SEcure Neighbor Discovery (SEND) specification
   (i.e. RFC3971) based on the existent experience and publish as
   draft standard.

- Define the MIB modules for SeND and CGAs and publish them
   as a Proposed Standard.

Related drafts:

draft-kempf-cgaext-ringsig-ndproxy-00.txt
draft-laganier-ike-ipv6-cga-02.txt
draft-jiang-sendcgaext-cga-config-00.txt

_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cga-ext

---

From: Wassim Haddad <[email-masked]>
Date: Sun, 30 Sep 2007 19:31:54 +0300 (EEST)

Hi Marcelo,

I'd like also to mention draft-haddad-cgaext-optisend-00.txt.
Comments appreciated!

Regards,

Wassim H.

On Sun, 30 Sep 2007, marcelo bagnulo braun wrote:

> Hi all,
>
> We have requested a slot for Vancouver for a bof on Cga and Send extensIons.
>
> well suited for environments with resource restrictions (CPU, storage,
> is much well suited for such environments and the lack of support of ECC
> provided. RFC4620 describes a protocol for asking an IPV6 node to supply
> protection against spoofing attacks and packet authentication mechanisms
> are provided.
>
> for which the certificate was allowed.  In order to facilitate issuance
> of certificates for specific functions, we need to encode the functions