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

[Wassim Haddad <[e-mail]>]

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.
>
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/cga-ext
>

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