Subject: Re: [CGA-EXT] [dhcwg] "Secure DHCPv6 Using CGAs"draft-jiang-dhc-secure-dhcpv6-01

From: Sean Shen <[email-masked]>
Date: Thu, 05 Feb 2009 16:24:18 +0800

Hi, Damien,
Sorry for the late response, I almost missed your email among tons of emails
after the long holiday. Please see in lines:

>On Jan 21, 2009, at 6:04 PM, Sean Shen wrote:
>>> I think you need to step back and figure out exactly what problem 
>>> you're trying to solve by adding this capability. Just beause we 
>>> could do something, doesn't mean we should.
>> The motivation and benefit (including advantages in relay scenarios 
>> and IP
>> binding) is described in section 3 of the draft.
>
>It's possible that this is just my lack of experience with 
>CGAs speaking, but section 3 hasn't enlightened me on the 
>benefit of this proposal.
Thanks for the comments. Based on the discussion recently, we are improving
the document by addressing the issues, including giving more and clearer
statement of benefit of the proposal. 

>My understanding is that CGA authentication will permit a 
>client to verify that a DHCP message received from a server 
>with a given address was, in fact, sent by the server with 
>that address.  Is there a mechanism, however, which permits 
>the client to verify that this server is authorized to act as 
>a DHCP server?  If not, what security is added by signing the message?
You are right that a public key itself does not include authorization info.
But it does not mean a malicious server is free to do configuration without
being punished. The characteristic of public key cryptosystem is that a pk
owner will be will be responsible for what he signed via his private key.
The pk owner surely can use his private key to play evil, but he will get
caught. For example, practically I can easily cheat on someone by using my
real identity, but I will never do that.
Attribute certificates include authorization info, but they are not included
in current CGA definitions, neither has I found its very necessary so far.
Thanks for your comments.

Best,

Sean