AUTHORIZATION ISSUES -------------------- 1. (2004-06-10, 12:43:01)bellovin: > I'm very concerned that the authorization model used by the authors is > incorrect. Several of the following comments, including the most > serious ones, are based on that belief. > > Section 4 says "A host and a router must have at least one common > trust anchor before the host can adopt the router as its default > router." I don't know what it means to "have ... a common trust > anchor", but the relationships are different. The host must believe > that the chain of authorizations, from the anchor to the router, > identifies a node that is *authorized* to route packets for this link. > That has nothing to do with whether or not the host in some way trusts > the anchor for other purposes. To give a concrete example, since > router certificates are tied to the addressing structure they're > presumably rooted at an RIR. That will be true of virutally all > router certificates describing public address space, including the > routers belonging to EvilHackerDudes.example.org. The fact that I'll > trust the certificates from routers for MyCompany.example.com doesn't > mean that I'll trust the evil ones. While trust anchors may suffice, > the spec must mandate some sort of user (or configuration) interface > to describe a full chain of authorized certificates. In some > situations, these may not be address certificates. A user sitting in > a public hot spot may be willing to trust the owner of the hotspot -- > say, via a standard commercial identity certificate, of the type used > today on the Web -- without regard to the particular addresses being > advertised or assigned. Reply: The authors agree with this comment, and had thought that, with the exception of utilizing commercial identity certificates, the spec did make this clear. Obviously, this wasn't the case. Note that the trust anchor could be at an RIR, but while waiting for that to happen, they could also be rooted at your home/company/ISP that you trust. In order to make the intent clearer, we propose the following changes in the specification. 1) Regarding utilizing standard identity certificates, suggest we change MUST to SHOULD in 6.1.1 regarding need for IP address extension, for example, first sentence in first paragraph. 2) Add Section 6.1.2 as follows: 6.1.2 Suitability of Standard Identity Certificates Since deployment of the IP address extension is, itself, not common, a network service provider MAY choose to deploy standard identity certificates on the router to supply the router's public key for signed Router Advertisments. A host interprets a standard identity certificate as having address authorization for the range 0::0 - ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff. In addition, if any certificate in the certificate path has an address range, then all certificates below it in the path MUST have an address range that is a subset of the range in the parent. Russ Housley: Rather than the hexidecimal representation, I think it will be more clear to say: "A host interprets a standard identity certificate as having address authorization for the entire range of addresses." 3) We will add the following sentence to the end of the first paragraph in Section 6.1: SEND hosts MUST additionally support a configuration interface that allows user configuration of acceptable certificate paths. Russ Housley: s/certificate paths/certification paths/ Russ Housley. This is not quite correct. What you want to do is configure trust anchors, and possibly associate address ranges with each trust anchor. Summarizing, we believe the intent -- maybe not the text? -- of the specification was that whatever trust roots are configured, they are strictly for SEND purposes only. That is, we do realize that there's a difference in authorizing for different tasks. That does not preclude the possibility of a user trusting the same certificate for different purposes, however. We also allow for a configuration of a multiple certificates, and address-less certificates (see Section 7.3 and unconstrained certificates). With the above change, we would also accept regular identity certificates. 2. (2004-06-10, 12:43:01)bellovin: > 6.2.1: Per my comments on Section 4, I'm not convinced that a trust > anchor is useful. Reply: Suppose we add the following definition to the Terminology section, Section 2: Trust Anchor Trust anchors are public keys that are typically contained in a self-signed certificates. The self-signed certificates may come from a variety of places, for example a root certificate authority, the host's network service provider, a Regional Internet Registry (RIR), or the Internet Assigned Numbers Authority. Trust anchors can also be configured out-of-band without requiring a self-signed certificate, for example, when a mobile device is purchased. Russ Housley: RFC 3280 does not require the use of self-signed certificates, and I am not sure that it is desirable to suggest their use here. 3. (2004-06-10, 10:02:50)rhousley > In section 5.2, the document says: > > > The Signature option allows public-key based signatures to be > > attached to NDP messages. Configured trust anchors, CGAs, or both are > > supported as the trusted root. > > The term "trusted root" is not explained. In fact, I do not think that > the traditional use of the term applies here. The public key that is > used to verify the signature is not contained in a certificate when a > CGA is employed. The processing to validate a public key needs to be > explained for each supported case. Reply: See above for a suggested definition of trust anchor. Is that OK? Russ Housley: Not really. See earlier comment. Regarding processing for CGA, a certificate is not necessary for a CGA key. The only property of interest is its tie to the address (the CGA property). The only case where a certified key is used is for validating router signatures on Router Advertisements. Suggest we remove the last sentence here, as it is misleading. Russ Housley: Okay. -------------------- Bellovin: real problem wasn't conveying authz, may want to trust Starbucks cert in Starbucks but not in office, not who issued, but knowing what cert expecting to see. Kempf: Reason for config interface? Bellovin: For routers, address extension is wrong because you don't know what addresses should be, trust site but everything else is taken, including address. Kempf: Match cert against advertised. Arkko: Optional, if someone wants to do it, delegating a specific part of address to router. One is compromised, could claim many addresses, if in cert can claim only its own addresses. Bellovin: Intent wasn't clear, authz needs to be done right. Bellovin: Addresses are useful in certs in end systems, if I want to talk to 1::2, know that. Arkko: Talking about advertised prefixes. Bellovin: Addresses are important. Aura: Use CGAs. Bellovin: If you use CGAs. Bellovin: Servers have fixed, easily memorable addresses. Kempf: Those could be in a certificate. Arkko: Do those need to be certified? Routers own address, does this need to be certified? Purpose of certificates is to trust router to do router stuff, also possible to certify prefixes, but if you have established that you trust router, not sure if its address makes a difference. Secure messages contain link layer addresses, don't see router's IP address. Arkko: Set of info advertised by router, IP address & prefixes are one, which ones are so important that in addition to trusting router, need specific authorization for parameters. Bellovin: Want IP address cert in certain circumstances or CGA. Servers will need certs. Deployment question, don't know yet. Arkko: Not opposed to addresses in certs, idea of prefixes is that prefixes will be visible globally, you generate an address when you communicate. Arkko: Two routers advertising two sets of routers advertising different prefixes, they are valuable. Action Item from Bellovin: Want a few paragraphs talking about authorization model, what is intended to be conveyed by the certs and certification path. When to trust something and when address ranges are useful and when not.