Hi, During IESG evaluation of draft-ietf-csi-proxy-send-04, Sandra Murphy pointed out that "I believe that a discussion is needed of what messages require or allow each particular key purpose authorization". draft-ietf-csi-send-cert-06 has been updated (in section 7) to provide more detail regarding to this issue.
However, in the process of addressing this comment, some authors of draft-ietf-csi-proxy-send and draft-ietf-csi-send-cert have arrived to a controversial point, which I refer to you, kindly requesting your opinion: In the current version of draft-ietf-csi-send-cert, 3 Key Purpose Id are defined: id-kp-sendRouter, id-kp-sendProxy and id-kp-sendOwner. The Key Purpose Id intended for proxy operation is id-kp-sendProxy. With the current wording, "The inclusion of the proxy authorization value (id-kp-sendProxy) indicates that the certificate has been issued for allowing the proxy to perform proxying of RA and Redirect messages for the prefix(es) that are mentioned in the X.509 extensions for IP addresses." it is not clear how a proxy requiring to proxy NA, NS and RS messages (in fact, the three application cases considered in draft-ietf-csi-proxy-send) would operate: a) Using id-kp-sendProxy for RA and Redirect, and id-kp-sendOwner for NA, NS, RS? My feeling is that id-kp-sendOwner should be reserved for hosts really owning the address, and not to be included in PS options. b) Modifying id-kp-sendProxy, extending the authorization to NA, NS and RS, so that id-kp-sendProxy authorizes ANY proxy operation However, another option, c) could be to have 2 Key Purpose Ids for proxy operation instead of one (therefore replacing id-kp-sendProxy), in which case the following text could be included in draft-ietf-csi-send-cert, section 7: "The inclusion of the proxied routing authorization value (id-kp-sendProxiedRouter) indicates that the certificate has been issued for allowing the proxy to perform proxying of RA and Redirect messages for the prefix(es) that are mentioned in the X.509 extensions for IP addresses. When a node's only certificate includes a prefix and only the id-kp-sendProxiedRouter authorization KeyPurposeId value, the node cannot perform proxying of NS, NA and RS messages. The inclusion of the proxied owner authorization value (id-kp-sendProxiedOwner) Indicates that the certificate has been issued for allowing the proxy to perform proxying of NS, NA and RS messages for any address in the prefix of such certificate. When a node's only certificate includes a prefix and only the id-kp-sendProxiedOwner authorization KeyPurposeId value, the node cannot advertise that prefix in an RA." The benefit of option c) is that proxy security is tailored to the proxy requirements, in the sense that different application scenarios may require one type of authorization, the other, or both. For example, MIPv6 would use a certificate with just id-kp-sendProxiedOwner, while PMIPv6 and RFC4389 would use a certificate with both id-kp-sendProxiedRouter and sendProxiedOwner. Compromising a MIPv6 HA would not allow an attacker to issue RA and Redirects. My personal opinion is that, to minimize security risks, authorization capabilities should not exceed the ones strictly required by the application scenario to be deployed, and two Key Purpose Ids for proxy operation provide appropriate granularity for this. (sorry if I fail to expose fairly the benefits of all options - feel free to comment, of course) For me, b) would acceptable, but I think c) should be better. What do you think? Regards, Alberto
_______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
