[CGA-EXT] Re: Charter and scope

[Jari Arkko <[e-mail]>]

> - do you think that the mib definition for SeND and CGAs are out of
> the scope? This seems to be not related to the usge of CGAs as a
> generic security tool...

That's right. I only took it out to reduce the number of work items to
those that seemed highest priority. But this is certainly something that
we should talk about.

> - i think we should also include an item that perform the rescorla
> bellovin analysis on the SeND spec (rfc3971) and to evaluate its
> dependency on SHA1 algorithm and eventually update rfc3971 to support
> multiple hash functions

Didn't we do this already?

> - in addition, we should also extend SeND spec (rfc3971) to support
> multiple public key algorithms, so send can use the other public key
> algorithms that are defind in the CGA update item...
> do you think it would make sense to include these additional items?

Yes, definitely. I may have forgotten that one out of the revision I
made. If so, apologies. That should definitely be there.

Jari
>
> regards, marcelo
>
> El 24/10/2007, a las 12:05, Jari Arkko escribió:
>
>> There's a bit of pushback from the security experts in
>> IESG and IAB to expand the scope of CGAs to generic
>> security mechanisms such as IKE. This pushback relates
>> to the question of key sizes as well as whether INT would
>> be the right place for such work. I tend to agree with this.
>>
>> In addition, taking another look at the charter now it seems
>> that it has a fair bit material in it. It might be better to focus
>> the work on improving the use of SEND/CGA for IP layer purposes.
>> This by itself is already a big effort.
>>
>> With that in mind, would the following reduced charter be
>> acceptable:
>>
>> 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 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. 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:
>>
>> - 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
>>   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.
>>
>> - 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 base specifications (RFC 3971 and 3972), if needed.
>>
>> 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