[CGA-EXT] Cga and Send extensIons (CSI) bof requested
marcelo bagnulo braun <marcelo@it.uc3m.es> Sun, 30 September 2007 15:09 UTC
Return-path: <cga-ext-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic0Q6-0003js-SZ; Sun, 30 Sep 2007 11:09:22 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic0Q4-0003iU-Pb; Sun, 30 Sep 2007 11:09:20 -0400
Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ic0Q0-00072f-NP; Sun, 30 Sep 2007 11:09:17 -0400
Received: from [192.168.1.129] (54.44.217.87.dynamic.jazztel.es [87.217.44.54])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp.uc3m.es (Postfix) with ESMTP id 69C12E3F7C;Sun, 30 Sep 2007 17:09:05 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <28F63372-A3AF-40A2-909B-82AAEB4D8319@it.uc3m.es>
Content-Transfer-Encoding: 7bit
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
Date: Sun, 30 Sep 2007 17:09:25 +0200
To: cga-ext@ietf.org
X-Mailer: Apple Mail (2.752.3)
X-imss-version: 2.048
X-imss-result: Passed
X-imss-scanInfo: M:B L:E SM:2
X-imss-tmaseResult: TT:1 TS:-21.0615 TC:1F TRN:71 TV:5.0.1023(15452.001)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
X-Spam-Score: 2.1 (++)
X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8
Cc: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Internet Area <int-area@ietf.org>
Subject: [CGA-EXT] Cga and Send extensIons (CSI) bof requested
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
Errors-To: cga-ext-bounces@ietf.org
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 CGA-EXT@ietf.org https://www1.ietf.org/mailman/listinfo/cga-ext
- [CGA-EXT] Cga and Send extensIons (CSI) bof reque… marcelo bagnulo braun
- Re: [CGA-EXT] Cga and Send extensIons (CSI) bof r… Wassim Haddad
- Re: [CGA-EXT] Cga and Send extensIons (CSI) bof r… Ana Kukec
- Re: [CGA-EXT] Cga and Send extensIons (CSI) bof r… James Kempf