[CGA-EXT] Re: Charter and scope

[marcelo bagnulo braun <[e-mail]>]

Hi Jari,

thanks for the feedback

i understand your point

Just a couple of obsrevations:

- 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...
- 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
- 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?

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