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 _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
