Re: [Int-area] CGA & SeND extensions discussion

["Jean-Michel Combes" <[e-mail]>]

Hi,

comments below.

2006/11/20, marcelo bagnulo braun <[e-mail]>:
> Hi,
>
> As a follow-up from James Kempf presentation in the Internet Area
> meeting in San Diego, we have created a mailing list to discuss
> potential future work related to CGA and SeND extensions. The main goal
> is to identify possible work items that the community is interested in
> doing some work on.
>
> You can subscribe to the list through:
> https://www1.ietf.org/mailman/listinfo/cga-ext

I think the old SEND ML still works :)

>
> I include a list of extensions that have been proposed over the last
> few years that could be possible candidates to work on, depending on
> the interest expressed. Please note that this is rough list, so maybe
> some of the items included may not be clearly within the scope of the
> work and there may be other items that i have missed.
>
> - Proxy SeND. The idea here is to define SeND and CGA extensions so
> that SeND can be used with Proxy ND. Reference:
> draft-kempf-mobopts-ringsig-ndproxy-01.txt
> - Define extensions to Multi-Key CGAs: The idea here is to allow the
> possibility of including multiple public keys in a single CGA
> Parameter Data Structure, so that multiple parties can claim address
> ownership. Reference: J. Kempf, J. Wood, Z. Ramzan, C. Gentry, "IP
> Address Authorization for Secure Address Proxying using Multi-key CGAs
> and Ring Signatures", IWSEC'06.

IMO, these 2 previous items are in fact in the same topic (i.e. the
second one as solution for the first one), aren't they?

> - Perform a threat analysis of the current dependency of CGAs with
> SHA-1 and Update CGAs so that other hash functions can be used. (this
> work is already been discussed in the Int area ml, but i guess it would
> benefit from additional discussion in a specialized forum). Reference:
> draft-bagnulo-multiple-hash-cga-01.txt
> - Define CGA extensions to support other public key algorithms. this
> would be a generic extension that would allow using other public key
> schemes in CGAs. In particular, the extension for using Elliptic Curve
> encryption have been suggested.

Agree with you about the 2 previous points: that will allow flexibility to CGA.

> - Usage of CGAs with IPSec. The goal here would be to use the key of
> the CGA to create an IPSec SA. Possible IKEv2 extensions need to be
> defined for this. Reference: draft-laganier-ike-ipv6-cga-01.txt

I strongly support such an item. It would be useful, for example, when
MIPv6-RO is secured with IPsec (i.e. draft-ietf-mip6-cn-ipsec-03.txt)
but no infrastructure (e.g. PKI) is available.

> - CGAs and DHCP. The goal here would be to analyze possible mechanisms
> to allow to assign CGAs using DHCP and to produce a recommendation
> about how this can be done. The actual DHCP extensions are to be
> defined in the DHC wg.

IKEv2 too: IMHO, it would be useful for IPv6 mobility bootstrapping.

> - Define CGA extensions for including Link Layer information in the
> CGA. Reference: draft-laganier-send-ll-hba-00.txt
> - Define CGA extensions to include a certified MAC address
> - Define CGA extensions to include symmetric keys. Reference:
> draft-narayanan-pba-01.txt
>
> Other items?

Do you plan to do a revision of the RFC 3971/3972 regarding potential
feedbacks from implementors?

Best regards.

JMC.

>
> comments on the items above?
>
> Regards, marcelo
>
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/int-area
>

_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area