Re: [Int-area] SeND & CGA Extensions BOF

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

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 <[e-mail]>:
> Hi,
>
> I support such a future work, specially the interaction between IKE and CGA.
>
> Best regards.
>
> JMC.
>
> 2007/6/1, marcelo bagnulo braun <[e-mail]>:
> > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/int-area
> >
>


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