[CGA-EXT] Re: Charter and scope

El 24/10/2007, a las 14:04, Jari Arkko escribió:

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

ok, i think we should do that, and i guess this shouldn't be too  
difficult

actually, i was reviewing rfc 3971 and it is written in such a way  
that would this work be quite straight forward imho... i mean, the  
"configuration" sections on each mayor part of the protocol basically  
defines the data strucutures that need to be managed, so this would  
simplify the task of defining the mib i think

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

we have done that for rfc3972 but not for rfc3971

i have been reviewing rfc3971 and there is some encoding of the sha1  
algorithm in there and it may worthwhile to do the rescorla bellovin  
analysis for that spec and see if it is needed to provide hash  
function agility

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

Actually this was my mistake (i forgot to include it in the charter  
proposal :-(

Regards, marcelo

> 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
CGA-EXT@ietf.org
https://www1.ietf.org/mailman/listinfo/cga-ext