Subject: [dhcwg] Follow up request for review of draft-ietf-csi-dhcpv6-cga-ps

From: Ralph Droms <[email-masked]>
Date: Tue, 14 Sep 2010 11:10:50 +0200

draft-ietf-csi-dhcpv6-cga-ps has been submitted to the IESG for publication.  Ted posted an announcement about draft-ietf-csi-dhcpv6-cga-ps in April, and I followed up in August.  I don't see a review of the doc in the cga-ext archive.  I would prefer to have a review of the doc from the dhc WG before starting an IETF last call; please respond with comments to [email-masked] and CCs [email-masked] and me.

Thanks...

- Ralph

=====

DHC working group members may be interested in reviewing this draft.   Please direct comments to the CGA working group (see the Reply-To: address on this message).

Begin forwarded message:

> From: marcelo bagnulo braun <marcelo at it.uc3m.es>
> Date: April 20, 2010 1:23:23 AM PDT
> To: "cga-ext at ietf.org" <cga-ext at ietf.org>
> Cc: "draft-ietf-csi-dhcpv6-cga-ps at tools.ietf.org" <draft-ietf-csi-dhcpv6-cga-ps at tools.ietf.org>
> Subject: [CGA-EXT] WGLC for draft-ietf-csi-dhcpv6-cga-ps-01.txt
> 
> Hi,
> 
> This note issues the WGLC for draft-ietf-csi-dhcpv6-cga-ps-01.txt
> Please, review the document and send your comments before april the 10th.
> 
> For your convenience, you can find the document at 
> 
http://datatracker.ietf.org/doc/draft-ietf-csi-dhcpv6-cga-ps/

> 
> Regards, marcelo
> 
> _______________________________________________
> CGA-EXT mailing list
> CGA-EXT at ietf.org
> 
https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Sep 2010 17:21:05 -0400

We've talked about the topics in this draft before at the DHC working group.   I just reread it, and the only thing I object to about it is the thing I've always objected to about it when it's come up in DHC meetings--the idea of offloading CGA generation work to the DHCP server.

This idea doesn't make sense to me from a security perspective--based on my probably naive understanding of CGA, it seems like this would mean that the private key would have to be sent over the wire in the clear.

I'd be happy to see this draft advance if the text about generating keys on the DHCP server were taken out.

---

From: Tony Cheneau <[email-masked]>
Date: Wed, 15 Sep 2010 00:08:42 +0200

Hello Ted,

> This idea doesn't make sense to me from a security perspective--based
> on my probably naive understanding of CGA, it seems like this would
> mean that the private key would have to be sent over the wire in the
> clear.
I apology for not speaking for this draft directly (I only read the
draft a long time ago). However, for a CGA to be computed (remotely or
locally), you only need few public parameters (subnet prefix, public
key and such).
Actually, the CGA document (RFC 3972) makes no use of the private key
during the CGA generation and verification process. This is why you
usually need SEND (or a similar mechanism) to achieve the proof of
ownership (through a signature realized by the private key).
So, as long as the public/private key are generated on the node, I
would say that you will not need to communicate the private key (in
clear or in a ciphered form).

Hope it helps.

Regards,
	Tony

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Sep 2010 19:06:46 -0400

> clear or in a ciphered form).

Actually, this is clear as mud to me.   What is the big compute job that's being done on the server, then?   Can you point me to the RFC I should be reading that explains all this?   Sorry to be obtuse.   :'}

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 15 Sep 2010 09:47:13 +0800

Hi, Ted,

There are actually two very different concerns you have. I reply below. 

Before that, I would like to state: as an informational document, draft-ietf-csi-dhcpv6-cga-ps aims
to analyze the all possible interactions between cga and dhcpv6. Whether these possibilities are
going to be defined as actual solutions in the future, it is another matter. In this draft, all we
say is there are such possibilities, their benefits and issues  (if you want, we can put more
analysis regarding to potential issues of this possibility). You may notice in this 04 version, we
have removed "Solution Requests" charpter, which was in previous version. We are not defining
solutions, even not requesting to define such solutions.

Your first concern is the security of this delegation operation. In all cases, the private key is
not transported through the network. The private key is only kept and used by its owner. This does
not say the delegation operation is security. Actually, other parameters and cga generation result
also need protection.  The existing security mechanism of DHCPv6 may be used. We can add more
clarification into the draft.

Your second concern is the big compute job may overload the server. True. Actaully, in this draft,
we state "The DHCPv6 server could then either compute the Modifier by itself, or redirect the
computation requirement to another server." The second server may be dedicated computational
server. Again, this draft only lists the possibilities. If you want, we can add more analysis on
the issues of this possibility.

Regards,

Sheng

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ted Lemon
> Sent: Wednesday, September 15, 2010 7:07 AM
> To: Tony Cheneau
> Cc: [email-masked] Group; [email-masked]; Droms; 
> [email-masked]
> Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review 
> ofdraft-ietf-csi-dhcpv6-cga-ps
> 
> Actually, this is clear as mud to me.   What is the big 
> compute job that's being done on the server, then?   Can you 
> point me to the RFC I should be reading that explains all 
> this?   Sorry to be obtuse.   :'}
> 
> [email-masked]

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 15 Sep 2010 08:56:01 -0700

Ted,

Some clarifications:

Ted Lemon wrote:
> Sent: Tuesday, September 14, 2010 4:07 PM
> To: Tony Cheneau
> Cc: [email-masked] Group; [email-masked]; Droms; [email-masked]
> Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review of draft-
> ietf-csi-dhcpv6-cga-ps
> 
> Actually, this is clear as mud to me.   What is the big compute job
> that's being done on the server, then?   Can you point me to the RFC I
> should be reading that explains all this?   Sorry to be obtuse.   :'}

If you have a look at the CGA generation algorithm described in RFC 3972 you will see that there are potentially two distinct computationally intensive tasks:

1. generation of public-private (RSA) key pair
2. generation of a CGA modifier value for a given Security Parameter (Sec) as per RFC 3972. (The Sec is used to harden the resistance of brute force attacks on the 64-bits IIDs of CGAs.)

#2 above might become computationally intensive for values of the Sec higher than zero (if it's zero any Modifier satisfies 3972). Back in 2002 I remember running the algorithm on then standard personal computers (e.g., x86 / ~1GhZ) and it would took ~20 seconds for Sec = 1 and a couple of minutes for Sec = 2. I do not remember going higher...

I understand the proposal is to offload #2 to the server while #1 would not be. 

IMHO it does not any make sense to offload when Sec is set to 0 because the computational load is nil. 

When Sec is set to 1 the computational load of #2 seems to be in the same order of magnitude as for #1, which does not necessarily means that offloading is useless as #1 might not need to be done by the constrained device itself (e.g., it's been offload to someone else, and result is stored on a smartcard.)

That being set I have not been convinced yet that there's a real world use case for Sec values higher than zero.

HTH,

--julien

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Sep 2010 19:39:54 -0400

> That being set I have not been convinced yet that there's a real world use case for Sec values higher than zero.

This does help, thanks.   I continue to think that the DHCP server is not a good place to offload the work, but I see the logic in wanting to do it, anyway, so I withdraw my objection.