DEPLOYMENT ISSUES ----------------- 4. (2004-06-10, 10:02:50)rhousley > In section 5.2.3, I expected some information about the source of > trust anchors. When I show up at an IETF meeting, how will my > laptop software learn the anchor for the IETF WLAN? If this > information is not going to be provided in this document, where can > I find it? One possible solution is to define a PKI that is rooted > at IANA. In this case, a single trust anchor is needed, so it can be > built into every implementation. However, there are several clues in > the document that indicate that a more local scheme is envisioned. Reply: The design does not envision a PKI rooted at IANA as the only solution. We believe this to be important for deployment. Suppose we add Section 6.3: 6.3 Decentralized Deployment Model The deployment model for trusted roots does not necessarily require a globally rooted public key infrastructure. A more local, decentralized deployment model similar to the current model used for TLS in Web servers is also possible. In this model, end hosts are configured with a collection of trusted public keys that form the trusted roots. Typically the public keys are contained in self-signed certificates, but it is also possible that a client might be preconfigured by some out-of-band mechanism with the name of a trusted root and its public key without having a self-signed certificate for the certification authority. The public keys could be issued from a variety of places, for example: a) a public key for the end host's home ISP and for ISPs with which the home ISP has a roaming agreement b) public keys for roaming brokers that act as intermediaries for ISPs that don't want to run their own certification authority c) public keys for Regional Internet Registries (RIRs), which are used for SEND and other secure routing purposes. End hosts need not be provisioned with their own certified public keys, just as Web clients today do not require end host provisioning with certified keys. Public keys for CGA generation do not in general need to be certified, since such keys derive their ability to authorize operations on the CGA by the tie to the address. Routers are configured with a collection of certificate paths that start at a similar set of trusted roots and a collection of certified keys and the certificates containing them, down to the key and certificate for the router itself. Certified keys are required for routers in order that a path of trust can be established between the router's certificate and the public key of a trusted root. 5. Ted Hardie: [2004-06-08] > I guess I have a fundamental design question. The draft describes part of the > underlying logic in section 6.1 as: > > The certificate chain of a router terminates in a Router > Authorization Certificate that authorizes a specific IPv6 node to act > as a router. Because authorization chains are not a common practice > in the Internet at the time this specification was written, the chain > MUST consist of standard Public Key Certificates (PKC, in the sense > of [19]). The certificate chain MUST start from the identity of a > trust anchor that is shared by the host and the router. This allows > the host to anchor trust for the router's public key in the trust > anchor. Note that there MAY be multiple certificates issued by a > single trust anchor. > > One of the common use cases for V6 is in mobile networks, where it > may be common for a terminal to operate in a network operated > by a provider to whom the user has no direct relationship. Managing > the trust anchors in this instance looks to be a fairly hard problem. > The draft doesn't seem to address this part of the problem > directly, though there is a bit of text on how fast hand-off may enable > one router to pass data on the next router along. > > Have I missed something here in the way of context or text? We don't think you missed any text, but this has certainly been considered in the design. First, there are two parts in the authorization problem related to ND: address ownership for nodes and the authorization of some nodes to be routers. We have solved the address part using CGAs, a zero-config scheme which works well in any type of roaming situation. The other part, routers, can not, as far as we know, be solved completely without some amount of configuration or infrastructure. However, the deployment model we are thinking of seems to work well even in a roaming scenario. Or so we think at least. Here's the idea: a node that moves around probably has a subscription with one or several operators that provides service in several locations. Either by themselves or through roaming relationships. Now, what is needed is that the mobile node gets a SEND root certificate from his operator(s). This certificate is not the one that is needed for access in a specific location X, but rather the root of such certificates. Then if you go to location X, the mobile node will get the local router's certificate and verify that it can be traced back to the root certificate. We also realize that deploying certificates can be troublesome. However, in the case of SEND the problem is not quite as bad as creating a global infrastructure. In particular, o SEND can operate (securely) from the start, even when, say, just your personal home network supports it but not other locations. o SEND requires certificates only for routers, not for all nodes (see CGA above). o SEND certificate hierarchies can be specific to your home/company/ISP/ISP roaming group, and do not need to be global. ------- Russ Housley: I agree [about not requiring IANA root]. However, that makes configuration of trust anchors vital. [On 6.3] Will there be a similar section on "Centralized Deployment Model"? and s/in general // I guess my comment about "trusted roots" was not clear. Please stop using this term. I would be much happier if the discussion of self-signed certificates was described as one option and that the trust anchor definition listed the items that are part od a trust anchor. This may be in the definition, or it may be in the body of the text: - a public key signature algorithm and associated public key, which may optionally include parameters; - an X.500 distinguished name; - (optional) a public key identifier; and - a list of address ranges. I do not like "path of trust." This is simply a certification path. Re: deployment and mobility. You do not propose any changes to the document in this discussion. Shouldn't some of this be provided as background? -------- Arkko: Deployment model question, how does this work in a mobile context, you trust some ISP, ISP has multiple locations, roaming relationships, root certificate from ISP will have to certify all locations. Bellovin: Same issue, how do you know who to trust? Arkko: Issue from Russ, is it RIRs or IANA. Russ: Need to remove Self signed certs references. Action item: reword to making clearer, drop keyword. -------- --------