[CGA-EXT] proposed csi charter text
marcelo bagnulo braun <marcelo@it.uc3m.es> Tue, 18 December 2007 14:07 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 1J4d6e-0003cD-T3; Tue, 18 Dec 2007 09:07:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4d6d-0003c7-4H for cga-ext@ietf.org; Tue, 18 Dec 2007 09:07:35 -0500
Received: from smtp03.uc3m.es ([163.117.176.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4d6c-0007JW-16 for cga-ext@ietf.org; Tue, 18 Dec 2007 09:07:35 -0500
Received: from [163.117.139.66] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.66])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id 77B6C296188for <cga-ext@ietf.org>; Tue, 18 Dec 2007 15:07:33 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <72D662E6-AF61-468C-82DD-65564307EF34@it.uc3m.es>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
To: cga-ext@ietf.org
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
Date: Tue, 18 Dec 2007 15:07:45 +0100
X-Mailer: Apple Mail (2.752.3)
X-imss-version: 2.049
X-imss-result: Passed
X-imss-scanInfo: M:B L:E SM:2
X-imss-tmaseResult: TT:1 TS:-21.2284 TC:1F TRN:89 TV:5.0.1023(15614.000)
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: -4.0 (----)
X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5
Subject: [CGA-EXT] proposed csi charter text
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, the bof in vancouver was very successful and we got very good feedback from the AD and the IAB. so the next step is to agree on the changes on the charter that were suggested on the BOF. After discussing with the Ad and the chairs, we propose to include in the charter a new item on certificate management to provide cert profile, cert validation and cert porisioning. We think that the anycast case that was suggested is not strictly clear that is within the scope of our work, so we prefer not to mention it explicitly in the charter, while it is possible to evaluate if the proposed solutions do work with anycast and eventually recharter later to include this work. the proposed charter so far is the following: We would like to send the charter to the AD in a week or so, so please provide feedback during the next week. Regards, marcelo Proposed charter for Cga & Send maIntenance (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. 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 RFC 4982. 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. While there is very little deployment of SEND to date, there are a number of implementations, recommendations in the NIST and DOD profiles call for use of SEND, and operating system vendors are considering adding SEND to their next releases. As a result, it is desirable to review the current state of the SEND and CGA specifications, maintain and complement them where necessary. Up to date cryptographic algorithms are needed, and the protocols need to be able to deal with certain common situations currently not supported. Specifically, the WG will look at the following issues: - Develop an informational document analyzing the implications of recent attacks on hash functions used by SeND protocol. Current SeND specification uses the SHA-1 hash algorithm and does not provides support for hash algorithm agility, hence the critical need for understanding the impact of the attacks on the SeND protocol. In addition, if as a result of the aforementioned analysis it is deemed necessary, standard-track extensions to the SeND protocol to support multiple hash algorithms will be defined. - Specify a standards-track CGA and SeND extensions to support multiple public key algorithms. As currently defined CGA and SeND can only use RSA keys, and they lack support for 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. - 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. - Develop X.509 certificate management tools 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. The WG will develop a certificate profile, including a definition of X.509 Extended Key Usage for SeND . In addition, the WG will recommend best practices for (1) enrollment, (2) revocation checking, and (3) publishing of certificates. This WG will ensure that the profile and recommended practices will cover usage by hosts in addition to routers. - Develop a standard track document defining a mechanism to perform SeND certificate provisioning for routers. SeND protocol as defined in RFC3971 specifies how IPv6 nodes can trust the prefixes advertised by a router. The solution is based on the use of the IP Address Delegation extension (RFC3779) in X.509 v3 certificates (RFC3280). This work will provide the tools require to provision with the certificates to the routers in an automatic manner. - Produce a problem statement document for Neighbor Discovery Proxies and then 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. - Develop an informational document analysing different approaches to allow SeND and CGAs to be used in conjunction with DHCP, and making recommendations on which are the best suited. Recharter based on the result of the analysis. - Update base specifications (RFC 3971 and 3972). Goals and Milestones: Jun 08 WG last-call on analysis of hash related threats in SeND Jun 08 WG last-call on Proxy-SeND problem statement Dec 08 WG last-call on Proxy SeND Dec 08 WG last-call on multiple hash function support in SeND, if required Set 08 WG last-call on CGA-DHCP interaction Set 08 WG last-call on multiple public key algorithm support for CGA Set 08 WG last-call on multiple public key algorithm support for SeND Dec 08 WG last-call on certificate profile definition for SeND Dec 08 WG last-call on certificate provision mechanism for SeND routers Dec 08 WG last-call on certificate management best practices for SeND routers Feb 09 WG last-call on updated SeND specification Feb 09 WG last-call on updated CGA specification Jul 08 Submit draft on analysis of hash related threats in SeND to IESG Jul 08 Submit draft on Proxy-SeND problem statement to IESG Jan 09 Submit draft on Proxy SeND to IESG Jan 09 Submit draft on multiple hash function support in SeND to IESG, if required Oct 08 Submit draft on CGA-DHCP interaction to IESG Oct 08 Submit draft on multiple public key algorithm support for CGA to IESG Oct 08 Submit draft on multiple public key algorithm support for SeND to IESG Jan 09 Submit draft on EKU definition for SeND to IESG Jan 08 Submit draft on certificate provision mechanism for SeND routers to IESG Jan 08 Submit draft on certificate management best practices for SeND routers to IESG Mar 09 Submit draft on updated SeND specification to IESG Mar 09 Submit draft on updated CGA specification to IESG _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www1.ietf.org/mailman/listinfo/cga-ext
- Re: [CGA-EXT] proposed csi charter text Jean-Michel Combes
- [CGA-EXT] proposed csi charter text marcelo bagnulo braun
- Re: [CGA-EXT] proposed csi charter text Jari Arkko
- Re: [CGA-EXT] proposed csi charter text marcelo bagnulo braun
- Re: [CGA-EXT] proposed csi charter text marcelo bagnulo braun
- Re: [CGA-EXT] proposed csi charter text Jean-Michel Combes
- RE: [CGA-EXT] proposed csi charter text Sheng Jiang