Hi, in fact I think I have an issue with SEND but I really don't know whether this BOF would be the right place or not.
Background: On one side, Prefix delegation (PD) protocols have been specified like the RFC 3633 based on DHCP, the draft "draft-ietf-nemo-prefix-delegation-01" for NEMO based on Mobility Header (MH) or the draft "draft-sarikaya-netlmm-prefix-delegation-00.txt" for PMIP based on DHCP/RADIUS/MH. On the other hand, if I remember correctly (I am not an certs expert), the CMS protocol allows to get certificates and can be transported over HTTP/TCP/MINE The issue, IMHO, is that it seems there is no easy/simple way to combine PD and certs generation in the case where you want to use SEND (the RtAdv security part). Am I wrong? If this is a real issue, where to do the work? In this BOF? In the PKIX WG? Comments are very welcome :) Best regards. JMC. 2007/6/5, Jean-Michel Combes <[EMAIL PROTECTED]>:
Hi, I support such a future work, specially the interaction between IKE and CGA. Best regards. JMC. 2007/6/1, marcelo bagnulo braun <[EMAIL PROTECTED]>: > Hi, > > we have proposed a BOF on SeND and CGA extensions for the Chicago IETF. > I attach the proposed charter below. There is a mailing list created > for the discussion (https://www1.ietf.org/mailman/listinfo/cga-ext) > > If you have comments about the proposed work, it would be appreciated. > > Thanks, marcelo > > > > Proposed charter for SeND & CGA Extensions BOF > > Secure Neighbour Discovery (SeND) protocol as defined in RFC 3971 > provides the security mechanisms to protecting the different > functions performed by the Neighbour Discovery (ND) protocol, > including the discovery of other nodes on the link and their > link-layer addresses, router discovery and reachability detection > for the paths to active neighbors. However, current SeND > specification lacks of support for ND Proxies as defined in > RFC 4389. The SeND protocol relies on the usage of > Cryptographically GEnerated Addresses (CGAs) to provide some of > these functions, in particular to provide IPv6 address ownership > proof to the other nodes on the link and authenticate node related > information of the ND protocol. CGAs are defined in RFC 3972 which > has been recently updated by RFC 4581 to define the CGA extension > format and by RFC-to-be draft-bagnulo-multiple-hash-cga-03.txt to > support multiple hash functions. 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. As the CGAs become more > widely used for different purposes, it is necessary to produce > some extensions to support such new usages. > > The objective of this working group is to define extensions related > to both to the SeND protocol and to the CGAs. The following are > charter items for the working group: > > - Extensions to the SeND protocol to support Neighbour Discovery > Proxies: SeND protocol as currently defined in RFC 3971 lacks of > support for ND Proxies defined in RFC 4389. Extensions to the SeND > protocol will be defined in order to provide equivalent SeND > security capabilities to ND Proxies. > > - Extensions to the IKEv2 protocol to create IPSec SAs associated to > the CGA key. Because of their cryptographic nature, CGAs are > inherently bound to the key pair that was used for their generation. > This is used in existent protocols for proving address ownership. > However, it would be possible also to use this cryptographic material > to create a security association between peers. The key benefit of > such approach is that it allows the creation of a security association > that is cryptographically bound to the IP address of the end points > without dependence on a common trust anchor point, eg. PKI. Such > approach would provide additional protection compared to the > opportunistic approaches. The proposed work will produce an analysis > of this type of solution and the required extensions to CGAs and to > the IKEv2 protocol in order to be able to create IPSec SA using the > CGAs keys. > > - DHCP support for CGAs. An analysis of possible approaches to allow > the usage of the DHCP protocol to assign CGAs will be produced. The > output of the analysis will be an informational document describing > the recommended approaches that will be provided as an input to the > DHC working group where the actual DHCP extensions needed for the > recommended approaches will be defined. > > - Define a CGA extension to support other public key algorithms: As > currently defined, CGAs can only use RSA keys in the CGA Parameter > Data Structure. An extension to update the CGA specification in > order to multiple public key cryptographic algorithm support will be > defined. > > > Related drafts: > > draft-kempf-mobopts-ringsig-ndproxy-01.txt > draft-laganier-ike-ipv6-cga-01.txt > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area >
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
