Francis Dupont writes and Jari Arkko responds: > - 6.3 Trusted Root Option (comment) > > => you don't support two root certificates for the same root... > I propose to add a name type where one can put a hash of the > certificate. For the hash itself the objectDigest seems perfect. Sounds good. Pekka? > BTW I don't understand why we should not put PKIX certificates? > IKEv2 does this, and it can make interoperability between implementations > less problematic. There's a pending discussion about the exact certificate types used. > - 6.5 Router Authorization Certificate Format (comment) > > MUST consist of standard Public Key Certificates (PKC, in the sense > of [11]) for identity from the trusted root shared with the host to > > => [11] (PKIX) doesn't use this term... IMHO the right reference is [12] > and the introduction text of [12] about PKC and AC should be copied! Sounds right. Pekka? > - same (comment) > > acinfo.attributes > > This field MUST contain a list of prefixes that the router is > authorized to route > > => I disagree: a router is not authorized to route a prefix, it is > authorized to advertise/annonce a prefix. About routing perhaps > it should be useful to authorize (or not) a router to be a default > router? Right. This has been covered under issue #5. > - same (comment) > > If the router is authorized only to route specific prefixes, the > ipAddress values consist of IPv6 addresses in standard RFC 3513 > [13] prefix format. > > => my problem is that ipAddress can't encode prefix in RFC 3513 format > (i.e., ipAddress can get a mask but not
/). > Please clarify, for instance with an example. RFC 3280 one is: > For example, a name > constraint for "class C" subnet 10.9.8.0 is represented as the octets > 0A 09 08 00 FF FF FF 00, representing the CIDR notation > 10.9.8.0/255.255.255.0. Ok. > PS: I can't find how to verify certified addresses, even for routers. > (this is not in 9.2) Indeed this is missing! --------------- James Kempf: Francis Dupont raised several issues about the certificate format in his review of the SEND draft. Rather than address these specific issues, however, I'd like to open the discussion somewhat wider, to include exactly what SEND should do w.r.t. a certificate profile for certifying advertised subnet prefixes by routers. A certificate profile for SEND seems advisable, since interoperability for certification verification is otherwise not assured, and such profiles have been necessary in other cases (example: TLS). The approach taken in draft-ietf-send-ipsec was to use RFC 3281 Attribute Certificates. The text in that draft specified certain conventions in using Attribute Certificates for SEND that would allow a host to determine whether a router was certified by a trusted intermediary to advertise a collection of subnet prefixes. Francis' comments addressed certain of the details specified in the draft that involved adapting Attribute Certificates to SEND. The specification in the draft did not include any support for certified prefix delegation. RFC 3281 forbids Attribute Certificate chains, so the specification included identity certification delegation through a chain of Identity Certificates, with the chain ending in an Attribute Certificate signed by the holder of the key certified in the last Identity Certificate. The host could certify the public key and thereby determine that the router was authorized to route the prefixes in the Attribute Certificate, but it couldn't trace back the prefix delegation. Subsequent discussion on the list and in Vienna established that some WG members wanted the ability to trace prefix delegation back to the trusted intermediary. There was some discussion in Vienna and on the list about modifying RFC 3281 to allow Attribute Certificate chains for this purpose. An alternative would be an Identity Certificate chain along with a set of paired Attribute Certificates for each prefix delegation. Russ Housley, AD for Security, recently advised Pekka and I that the PKIX WG has been dealing with the same issue in the context of SBGP. The goal there is to allow any entity that receives a prefix delegation - ISPs, enterprises, routers, etc. - to verify the delegation. The solution is described in draft-ietf-pkix-x509-ipaddr-as-extn-01.txt. This draft is now in Last Call in the PKIX WG. In this solution, no Attribute Certificates are used. Instead, the delegating entity adds a few attributes to a standard Identity Certificate and signs the certificate, thereby certifying the prefix delegation. The draft supports a variety of delegation designations, one being a prefix format similar to that specified in draft-ietf-send-ipsec. In Appendix C, the draft goes on to argue that Attribute Certificates are the wrong mechanism for address prefix delegation because: 1) The certificates used for prefix delegation are used exclusively for that purpose, so their lifetimes would match exactly that of an Identify Certificate used to certify identity. One reason for using Attribute Certificates cited in RFC 3281 is that the lifetimes of the attribute certification and identity certification would differ. 2) The certificate hierarchy is constructed so that the certificate issuer is also authoritative for the prefix delegation authorization. For example, if an ISP receives a certified delegation from an RIR, then the RIR is both the certificate issuer and the source of certification for the prefix delegation authorization. Another reason for using Attribute Certificates cited in RFC 3281 is that the issuer of the Identity Certificate and Attribute Certificate are different. Appendix C goes on to list several other requirements for applicability of Attribute Certificates in RFC 3281 that it claims are not applicable to certifying prefix delegation. With reference to the above discussion, the following are possible alternatives for generating a certificate profile: A) We could ignore prefix delegation and even prefix certification entirely, and just have the host certify the router's identity. The certificate profile would specify standard RFC 3280 Identity Certificates with perhaps some conventions on the name used for identity determination, but no special prefix attributes. Later, if prefix certification or delegation certification becomes important, the modified profile could be specified in a separate draft. B) We could ignore prefix delegation but provide support for prefix certification by using Attribute Certificates, as in draft-ietf-send-ipsec. Again, if delegation certification proved important, it could later be specified in a separate draft. C) We could support delegation using a parallel Attribute Certificate chain, along with the Identity Certificate chain. Each Attribute Certificate would be signed by the public key certified by the holder of the delgeating authority's Identity Certificate. Note that this might require a change in the DCA mechanism to handle the increased (potentially double) certificate exchange load. D) We could talk to Russ and Steve Bellovin about opening up RFC 3281 to allow Attribute Certificate chains to support prefix delegation certification. We would probably have to specify the certificate profile for SEND in a separate draft if we did this, since modifications for RFC 3281 might take a while. E) We could support delegation through using the mechanism described in draft-ietf-pkix-x509, with perhaps some minor specification of conventions to satisfy SEND requirements. Comment from the WG on these options, preferences, and any additional options that might have been missed is invited. --------------- James Kempf: The email on proposed solutions to Issue 20 generated no comment from the WG. In the interest of having a unified IETF certificate profile for routing certificates, I'd suggest we go forward with proposal E: Support delegation through using the mechanism described in draft-ietf-pkix-x509, with perhaps some minor specification of conventions to satisfy SEND requirements. This will set up a normative reference dependency between the SEND drafts and draft-ietf-pkix-x509, requiring that draft to advance to PS before SEND does. Since I took the action item in Vienna to look into the cert profile, I will study draft-ietf-pkix-x509 and see whether any additional specification is required for SEND. If so, I will provide Jari with text describing it. If not, the section on the SEND certificate profile will have a single sentence, referring to draft-ietf-pkix-x509. --------------- Pekka Nikander: > The email on proposed solutions to Issue 20 generated no > comment from the WG. After having thought about this for quite a while, and considering the long and short term pros and cons of different approaches, I have come to the following conclusions: > A) We could ignore prefix delegation and even prefix certification ' > entirely, and just have the host certify the router's identity. A) would be pretty bad from the security point of view, and it would not fulfil many of the goals in the psreq draft. > B) We could ignore prefix delegation but provide support for prefix > certification by using Attribute Certificates, B) would be acceptable to me. On the other hand, we would have to understand the scalability consequences. > C) We could support delegation using a parallel Attribute > Certificate chain, along with the Identity Certificate chain. C) would be close to the "right" approach, but result in very complex operations in the hosts. I don't like that kind of unnecessary complexity. > D) We could talk to Russ and Steve Bellovin about opening up > RFC 3281 to allow Attribute Certificate chains to support > prefix delegation certification. In my opinion, D) would be the architecturally right choice. However, this would take quite a long time, and might even fail. > E) We could support delegation through using the mechanism > described in draft-ietf-pkix-x509, Even though I don't like E) from an architectural point of view, it looks acceptable. It is simple enough to define, simple enough to implement, secure, and scales appropriately. It also delegates the hard problem of setting up the infrastructure to another WG. > In the interest of having a unified IETF certificate profile for routing > certificates, I'd suggest we go forward with proposal E: > > Support delegation through using the mechanism described in > draft-ietf-pkix-x509, with perhaps some minor specification of conventions > to satisfy SEND requirements. Based on my conclusions above, I find this proposal good. --------------- Pekka Nikander: I believe that I have now resolved the majority of the certificate issues, as discussed on the list on issue #20. I still need to check that this covers all comments on issue #08, but I'll do that later. The new certificate text reads as follows: 6.5 Router Authorization Certificate Format 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 is being written, the chain MUST consist of standard Public Key Certificates (PKC, in the sense of [22]). The certificates chain MUST start from the identity of a trusted root that is shared by the host and the router. This allows the host to anchor trust for the router's public key in the trusted root. Note that there MAY be multiple certificates issued by a single trusted root. 6.5.1 Router Authorization Certificate Profile Router Authorization Certificates MUST contain the X.509 extension for IP addresses, as defined in [13]. The parent certificates in the certificate chain MUST contain one or more X.509 IP address extensions, back up to the delegating authority (the Regional Address Registry or IANA) that delegated the original IP address space block. The certificates for intermediate delegating authorities MUST contain X.509 IP address extension(s) for subdelegations. The router's certificate is signed by the delegating authority for the prefixes the router is authorized to to advertize. The X.509 IP address extension MUST contain at least one addressesOrRanges element that contains an addressPrefix element with an IPv6 address prefix for a prefix the router or the intermediate entity is authorized to advertize. If the entity is allowed to route any prefix, the used IPv6 address prefix is the null prefix, 0/0. The addressFamily element of the containing IPAddrBlocks sequence element MUST contain the IPv6 AFI (0002), as specified in [13] for IPv6 prefixes. Instead of an addressPrefix element, the addressesOrRange element MAY contain an addressRange element for a range of prefixes, if more than one prefix is authorized. The X.509 IP address extension MAY contain additional IPv6 prefixes, expressed either as an addressPrefix or an addressRange. A SEND node receiving a Router Authorization Certificate MUST first check whether the certificate's signature was generated by the delegating authority. Then the client MUST check whether all the addressPrefix or addressRange entries in the router's certificate are contained within the address ranges in the delegating authority's certificate, and whether the addressPrefix entries match any addressPrefix entries in the delegating authority's certificate. If an addressPrefix or addressRange is not contained within the delegating authority's prefixes or ranges, the client MAY attept to take an intersection of the ranges/prefixes, and use that intersection. If the addressPrefix in the certificate is the null prefix, 0/0, such an intersection SHOULD be used. (In that case the intersection is the parent prefix or range.) If the resulting intersection is empty, the client MUST NOT accept the certificate. The above check SHOULD be done for all certificates in the chain received through DCA messages. If any of the checks fail, the client MUST NOT accept the certificate. Since it is possible that some PKC certificates used with SEND do not immediately contain the X.509 IP address extension element, an implementation MAY contain facilities that allow the prefix and range checks to be relaxed. However, any such configuration options SHOULD be off by default. That is, the system SHOULD have a default configuration that requires rigorious prefix and range checks. Comments? Considering the minor points, I have resolved them as follows: > Francis Dupont writes and Jari Arkko responds: > >> - 6.3 Trusted Root Option (comment) >> >> => you don't support two root certificates for the same root... >> I propose to add a name type where one can put a hash of the >> certificate. For the hash itself the objectDigest seems perfect. > > Sounds good. Pekka? The text has now been clarified that a host may be configured with several trusted root, and that there may be several certificates issued by a trusted root. The idea of using hashes to identify trusted roots were not adopted. >> BTW I don't understand why we should not put PKIX certificates? >> IKEv2 does this, and it can make interoperability between implementations >> less problematic. > > There's a pending discussion about the exact certificate types > used. The new text indeed uses PKC certificates, with the IP address extension. >> - 6.5 Router Authorization Certificate Format (comment) >> >> MUST consist of standard Public Key Certificates (PKC, in the sense >> of [11]) for identity from the trusted root shared with the host to >> >> => [11] (PKIX) doesn't use this term... IMHO the right reference is [12] >> and the introduction text of [12] about PKC and AC should be copied! > > Sounds right. Pekka? Used RFC3281 as the reference. Moved RFC3281 is now an informational reference instead of normative. >> - same (comment) >> >> acinfo.attributes >> >> This field MUST contain a list of prefixes that the router is >> authorized to route >> >> => I disagree: a router is not authorized to route a prefix, it is >> authorized to advertise/annonce a prefix. About routing perhaps >> it should be useful to authorize (or not) a router to be a default >> router? > > Right. This has been covered under issue #5. Changed all text to read that a router/entity is authorized to advertize a prefix, not to route it. >> - same (comment) >> >> If the router is authorized only to route specific prefixes, the >> ipAddress values consist of IPv6 addresses in standard RFC 3513 >> [13] prefix format. >> >> => my problem is that ipAddress can't encode prefix in RFC 3513 format >> (i.e., ipAddress can get a mask but not
/). >> Please clarify, for instance with an example. RFC 3280 one is: >> For example, a name >> constraint for "class C" subnet 10.9.8.0 is represented as the octets >> 0A 09 08 00 FF FF FF 00, representing the CIDR notation >> 10.9.8.0/255.255.255.0. > > Ok. This comment does not apply any more as we have changed the certificate format. >> PS: I can't find how to verify certified addresses, even for routers. >> (this is not in 9.2) > > Indeed this is missing! I removed the remaining text that discussed certifying router's addresses. --------------- --------------- --------------- ---------------