Subject: [CGA-EXT] CGA & SeND extensions discussion

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 20 Nov 2006 13:17:42 +0100

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

comments on the items above?

Regards, marcelo

_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cga-ext

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 20 Nov 2006 15:26:58 +0200 (EET)

Hi Marcelo,

We also would like to include the ongoing SEND Optimization (OptiSEND)
work (draft-haddad-mipshop-optisend-02).

Regards,

Wassim H.

On Mon, 20 Nov 2006, marcelo bagnulo braun wrote:

> Int-area mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/int-area
>
>

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 21 Nov 2006 20:22:36 +0100

Hi,

comments below.

> https://www1.ietf.org/mailman/listinfo/cga-ext

I think the old SEND ML still works :)

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

> encryption have been suggested.

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

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

> about how this can be done. The actual DHCP extensions are to be

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

> draft-narayanan-pba-01.txt

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

Best regards.

JMC.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 21 Nov 2006 11:38:01 -0800

> about how this can be done. The actual DHCP extensions are to be 

Why not just have:

  1) Client configures an address using CGA and includes it in
     an IA_NA; IA_TA option in its initial solicitation.
  2) Server determines whether the client's proposed (CGA-based)
     address is unique and returns an appropriate status code.
  3) Client assigns the address to an interface, or proposes
     a new CGA to the server if earlier attempts collided.

I don't think there are any DHCP extensions required for that?

Fred
[email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Nov 2006 21:41:58 +0100

>      a new CGA to the server if earlier attempts collided.

Sounds good at delivering hash-based addresses to terminal. It may
however have security risks, like a rogue Server.

> I don't think there are any DHCP extensions required for that?

There could be a discussion on securing initial DHCPv6 exchanges with
hash-based addresses instead of shared IPsec keys, too.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Tue, 21 Nov 2006 13:56:44 -0800

> second one as solution for the first one), aren't they?

Actually, there are other uses for multikey CGAs besides proxying. For 
example, it makes it possible to configure all access routers in an area 
with the same link local address, and still be able to have them use SEND, 
without requiring them to share a private key. Also, it can be used for 
route optimization in NEMO (paper available on request, somewhat speculative 
however).

And there are other solutions for proxy SEND. For example, having the node 
simply trust the proxy based on the proxy's certificate, or having the node 
supply the proxy with an attribute certificate allowing the proxy to claim 
and defend the address.

            jak

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 22 Nov 2006 09:23:39 +0100

Hi,

Sorry but I need a clarification :)
Marcelo's item about DHCP is about how may DHCP provide a CGA address
to a node or how does DHCP check that a node may use a CGA address?

Thanks.

Best regards.

JMC.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 22 Nov 2006 17:12:44 +0100

Hi,

I think that there are different ways that DHCPs and CGAs could 
interact and i guess that the first thing that is needed is to identify 
which of those are valuable and workable.

I can see at least the following modes of interaction:

- the end node generate the CGA and registers it to the dhcp server. 
(as Fred suggests)

- the end node generates the key pair, submit the public key to the 
DHCP server and the DHCP server generates the CGA and informs the end 
node about the CGA and the CGA parameter data strucutre. This could be 
useful, for instance if the dhcp server wants to include additional cga 
extensions in the CGA parameter data strucutre. for example, the dhcp 
server could include another public key (on the case of multikey cgas) 
or could include a HBA extension (so that the server makes sure that 
all the prefixes are included in the CGA/HBA generation)

- the server generates the key pair and then the CGA Parameter data 
strucutre. It then conveys the key pair, the CGA and the CGA parameter 
data strucutre to the node. this could provide key escrow, or key 
generation for devices that are not powerful enough to generate the key 
pair. This could be especially true for high values of sec. Of course 
this option presents security concerns that need to be properly 
addresses.

- as i understand Alex suggestion, it could also be envisioned to 
secure the dhcp exchange using CGAs... not sure i understand in which 
scenario would this be useful...

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 22 Nov 2006 17:15:19 +0100

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

i don't understand what do you mean here... could you expand?

> feedbacks from implementors?

this could be very useful indeed...

do you know any comment form implementors that need to be addressed?

Regards, marcelo

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 23 Nov 2006 16:36:36 +0100

> i don't understand what do you mean here... could you expand?

When IKEv2 assigns the HoA to the MN. This one could be CGA based
(BTW, this is linked to the Proxy SEND item mentioned in your first
email).

> do you know any comment form implementors that need to be addressed?

No. But when the RFC will advance to Draft Standard, we will need some
(at least, interoperability feedbacks).

Best regards.

JMC.