hi, Bernie, Please see in lines. >If we want to replace IPSec with something else for relay to >relay/relay to server communication, we could always just >allow use of the AUTH option. There's little need for CGA. It can be a try if you want to use AUTH for relay-->relay/relay-->server, but I doubt it can fit the scenario well. AUTH is basicly symmetric crypto, good for two parties. It's rare to use it for 3 or more parties because you don't want to manage keys for each pair of parties. Also if you want your AUTH be checked by all the nodes on the route, you have to calculate and carry multiple AUTHs for all of them, while RFC3315 clearly defined that only one AUTH can be used, not mentioing that a client may not even know which router will check the AUTH (hence don't know which key to use). Since I am not an author of RFC3315, I don' t know other reasons (besides what I just said above) that AUTH is not simply used in relay scenarios. If you think it's doable, more discussion of its feasibility will be interesting.
>However, I don't believe there's a need to find an alternative >to IPSec. The reason is simple: NOT all routers can and like to use IPsec. >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. >Personally, I still find that using the keys used by SEND >(CGA) with the AUTH option to authentication servers (and >possibly clients to servers) is the most interesting beause if >you've already distributed those keys, it avoids having to >distribute yet another set of keys. And, the folks that manage >the routers often manage the DHCPv6 servers as well. Generally using same key for multiple purposes should be avoided in crypto (unless good hash processing involved), just like you don't want to use a same key for both encryption and authentication. Again we said before, the reason is not only about key management. Best, Sean _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
