Hi Alberto, Please see inline. > 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:
Actually, the text you are referring is already a modified version of the original text that got WGLC. That text represented your option b). > 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: I take option c). When I first thought about this, I remembered the old times of modem access and Proxy-ARP in routers. I see now a use-case for "id-kp-sendProxiedOwner" even without considering MIP6. I agree that we should go this path, it will make a better set of documents. However, I believe that if we go this path, we need also to make sure that there is a synchronization between this document and the proxy document to reflect the correct sender/receiver behavior. Finally, I would like to clarify the validation behavior when listen several EKUs in a certificate. At this time, the document states that the existence of a particular EKU is a sufficient condition. This means that if a certificate has a id-kp-sendProxiedRouter and a id-kp-sendRouter EKU and I am validating a RA with or without the proxy option, it will validate in either cases using the same key. I believe this should be the correct behavior as it should be the operator to decide how it want to configure its network. Regards, Roque > > “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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
