Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
in operation, this means that there could be isp- (or ufo-)centric isp identity certification (a la web of trust, for example) which could have a very separate cert chain from that of address space allocation, which, aside from the legacy issue, could come via the rirs.
So when one receives an update, which part is it that you verify with the certificate derived from the RIR chain and which part is it that you verify with the certificate derived from the web-of-trust? I'm guessing the answer in part is that there's a signature attesting to the prefix origination based on the RIR-rooted certificate, but I'm not certain what you are suggesting you would sign with the web-of-trust based ISP identity certificate (the origination announcement, indicating that it is not only authorization to originate but also source authentication?) If the RIR-rooted certificate says that ISP XYZ is allocated prefix P, does the web-of-trust ISP identify certificate have to say exactly "ISP XYZ"? Is that exact match the link between what the RIR-rooted cert is proving and what the web-of-trust identify cert is proving? --Sandy
So when one receives an update, which part is it that you verify with the certificate derived from the RIR chain and which part is it that you verify with the certificate derived from the web-of-trust? I'm guessing the answer in part is that there's a signature attesting to the prefix origination based on the RIR-rooted certificate, but I'm not certain what you are suggesting you would sign with the web-of-trust based ISP identity certificate (the origination announcement, indicating that it is not only authorization to originate but also source authentication?)
something like the rir attests to the delegation of the prefix and an asn to the identified isp. the isp signs, using their isp identity to o originating from the asn o originating that prefix (in sbgp, toward another isp) o possibly delegating a subset of that prefix o passing other prefixes on (in sbgp, toward ...) but either you, smb, or jis should be able to get it more correctly than i. randy
According to what I understand, there have to be two certificates per entity: one is the CA-bit enabled certificate, used to sign subsidiary certificates about resources being given to other people to use. the other is a self-signed NON-CA certificate, used to sign route assertions you are attesting to yourself: you make this cert using the CA cert you get from your logical parent. -George
In message <20051124113104.0bd275d2@garlic.apnic.net>, George Michaelson writes :
According to what I understand, there have to be two certificates per entity:
one is the CA-bit enabled certificate, used to sign subsidiary certificates about resources being given to other people to use.
the other is a self-signed NON-CA certificate, used to sign route assertions you are attesting to yourself: you make this cert using the CA cert you get from your logical parent.
Or your parent could have a CA and issue you two certs, one for signing route assertions and one for signing certificates you issue to your downstreams. That in turn has another interesting implication: an ISP can *enforce* a contract that prohibits a downstream from reselling connectivity, at least if the resold connectivity includes a BGP announcement -- the ISP would simply decline to sign a CA certificate for its customer, thereby depriving it of the ability to delegate portions of its address space. (N.B. Certificates include usage fields that say what the cert is good for.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
On Thu, 24 Nov 2005, George Michaelson wrote:
According to what I understand, there have to be two certificates per entity:
one is the CA-bit enabled certificate, used to sign subsidiary certificates about resources being given to other people to use.
the other is a self-signed NON-CA certificate, used to sign route assertions you are attesting to yourself: you make this cert using the CA cert you get from your logical parent.
So how is the 2nd one different from the first? In both cases you give permission to certain use of a resource under your control. If you look at it the only difference is: - To authorize reallocations you sign request based on another entity's ORG object, - To authorize announcement you sign request based on another entity's ASN object (can be your own ASN). But in general ASN object is also basically a type of ORG with extra data (i.e. ASN# and ASN name), so I don't see why you can't use one cert (if somebody does not list AS# for their org I guess they can't route independently). -- William Leibzon Elan Networks william@elan.net
On Wed, 23 Nov 2005 17:54:44 -0800 (PST) "william(at)elan.net" <william@elan.net> wrote:
On Thu, 24 Nov 2005, George Michaelson wrote:
According to what I understand, there have to be two certificates per entity:
one is the CA-bit enabled certificate, used to sign subsidiary certificates about resources being given to other people to use.
the other is a self-signed NON-CA certificate, used to sign route assertions you are attesting to yourself: you make this cert using the CA cert you get from your logical parent.
So how is the 2nd one different from the first?
the important distinction is that the certificate used to sign resource assertions doesn't have the CA bit set. -George
In message <20051124120010.2c2aed2a@garlic.apnic.net>, George Michaelson writes :
On Wed, 23 Nov 2005 17:54:44 -0800 (PST) "william(at)elan.net" <william@elan.net> wrote:
On Thu, 24 Nov 2005, George Michaelson wrote:
According to what I understand, there have to be two certificates per entity:
one is the CA-bit enabled certificate, used to sign subsidiary certificates about resources being given to other people to use.
the other is a self-signed NON-CA certificate, used to sign route assertions you are attesting to yourself: you make this cert using the CA cert you get from your logical parent.
So how is the 2nd one different from the first?
the important distinction is that the certificate used to sign resource assertions doesn't have the CA bit set.
More generally.... To a 0th and even a 1st approximation, a certificate is just a binding of a public key to an identity. But there's far more complexity, much of it actually necessary, to real X.509 certificates, or the PKIX working group wouldn't have churned out 32 RFCs... One thing important here is the usage fields. For example, I just went to https://www.microsoft.com and looked at its cert. Under "Certificate Key Usage", it says "Signing" and "Key Encipherment". There's another field, "Extended Key Usage", that Firefox can't decode. There are other certificates, issued by Microsoft, that are identified as code-signing certificates. Here, we need several forms. One is just for communicating with the RIR(s); that's a pretty ordinary identity cert. We need an AS cert (at least for some proposals); that coudl be an identity cert, but with a name of a special form. We need prefix ownership certs; these need a special field identifying the prefix owned. (See RFC 3779, which also describes AS certificates). We need the latter in CA form, for delegation. There are probably a few more, depending on just how we decide to secure BGP. The purpose of all of these distinctions is to permit control over how certificates are used, without relying on special-format names. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
We need prefix ownership certs; these need a special field identifying the prefix owned. (See RFC 3779, which also describes AS certificates). We need the latter in CA form, for delegation.
sorry to complicate, by iana allocates as ranges which are then subbed to rirs. so the ca bit could be set on these randy
On Wed, 23 Nov 2005 17:42:21 -1000 Randy Bush <randy@psg.com> wrote:
We need prefix ownership certs; these need a special field identifying the prefix owned. (See RFC 3779, which also describes AS certificates). We need the latter in CA form, for delegation.
yes. the resource certs we are making, the test certs, have CA bit set, and include RFC3779 fields for ASN, IPv4 and IPv6 ranges, using the range ASN.1 notation for ASN ranges.
sorry to complicate, by iana allocates as ranges which are then subbed to rirs. so the ca bit could be set on these
for the APNIC resource certificates in test, they are. cheers -George
randy
-- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton Phone: +61 7 3858 3150 | QLD 4064 Australia Fax: +61 7 3858 3199 | http://www.apnic.net
In message <17285.13981.462449.539200@roam.psg.com>, Randy Bush writes:
We need prefix ownership certs; these need a special field identifying the prefix owned. (See RFC 3779, which also describes AS certificates). We need the latter in CA form, for delegation.
sorry to complicate, by iana allocates as ranges which are then subbed to rirs. so the ca bit could be set on these
I thought I'd mentioned earlier that we may want two different forms of prefix cert, with with CA and one without. The one without goes in the routers; the one with CA is used to issue certs to downstreams. Rationale for the two certs: if a router is badly 0wned, someone can steal its private key and use it for address hijacking. But that sort of gross abuse of an entire prefix is likely to be noticed. A CA cert can be used to issue certs for longer prefixes, i.e., target one customer, rather than an entire ISP. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
According to what I understand, there have to be two certificates per entity:
one is the CA-bit enabled certificate, used to sign subsidiary certificates about resources being given to other people to use.
the other is a self-signed NON-CA certificate, used to sign route assertions you are attesting to yourself: you make this cert using the CA cert you get from your logical parent.
probably more. smb has convinced me that the (possibly ca[0]) cert i get from the rir, with which i do business with the rir (dns, ip requests, billing), should be different than that which i use for routing info. randy --- [0] - i'll want the business cert to have the ca bit if i am large enough to have internal authorization process, and thus want to create and manage different certs for dns, billing, ...
On Wed, 23 Nov 2005 16:03:35 -1000 Randy Bush <randy@psg.com> wrote:
According to what I understand, there have to be two certificates per entity:
one is the CA-bit enabled certificate, used to sign subsidiary certificates about resources being given to other people to use.
the other is a self-signed NON-CA certificate, used to sign route assertions you are attesting to yourself: you make this cert using the CA cert you get from your logical parent.
probably more. smb has convinced me that the (possibly ca[0]) cert i get from the rir, with which i do business with the rir (dns, ip requests, billing), should be different than that which i use for routing info.
At APNIC the cert we expect you to identify yourself with to transact with the registry is not the same as the cert which identifies resource utilization. But we (APNIC) also expect to use a different root CA for these 'identity' certs anyway. the test APNIC resource certificates are using an interim self-signed CA, and will be moving to a hardware-token secured CA shortly. The hardware is the same as our identity certificates used in MyAPNIC, but a different trust anchor and CA identity will be used for resource certificate processes. We probably need to make this explict in our policies in this area. We've always cheers -George
randy
---
[0] - i'll want the business cert to have the ca bit if i am large enough to have internal authorization process, and thus want to create and manage different certs for dns, billing, ...
We are discussing how we can do subsidiary certificate services like this in APNIC but I think this goes outside of routing policy and into registry business practices which are unlikely to be common for all RIR and NIR in the ways that resource certificates *have* to be. cheers -George
[0] - i'll want the business cert to have the ca bit if i am large enough to have internal authorization process, and thus want to create and manage different certs for dns, billing, ...
We are discussing how we can do subsidiary certificate services like this in APNIC but I think this goes outside of routing policy and into registry business practices which are unlikely to be common for all RIR and NIR in the ways that resource certificates *have* to be.
if it is not common across registries, and if my certs do not work across registries, then something is very very broken, and a major pita at the isps', aka your members', expense. randy
On Wed, 23 Nov 2005 16:39:11 -1000 Randy Bush <randy@psg.com> wrote:
[0] - i'll want the business cert to have the ca bit if i am large enough to have internal authorization process, and thus want to create and manage different certs for dns, billing, ...
We are discussing how we can do subsidiary certificate services like this in APNIC but I think this goes outside of routing policy and into registry business practices which are unlikely to be common for all RIR and NIR in the ways that resource certificates *have* to be.
if it is not common across registries, and if my certs do not work across registries, then something is very very broken, and a major pita at the isps', aka your members', expense.
randy
If you want to see member-certificates which gate access to RIR/NIR specific services common across all registries, I think you want to get that onto an RIR meeting agenda Randy. We currently have no cross-certification activity in member identity. cheers -George
We are discussing how we can do subsidiary certificate services like this in APNIC but I think this goes outside of routing policy and into registry business practices which are unlikely to be common for all RIR and NIR in the ways that resource certificates *have* to be.
if it is not common across registries, and if my certs do not work across registries, then something is very very broken, and a major pita at the isps', aka your members', expense.
If you want to see member-certificates which gate access to RIR/NIR specific services common across all registries, I think you want to get that onto an RIR meeting agenda Randy.
i have been whining about the problems of cross-registry operation for over a decade, formally, informally, presos, ... i have had it on every rir's meeting agenda (except lacnic) for many years. do i need to iterate for every ort of service the registries provide? we are the registries' customers. many of us, especially the ones who pay the registries the most, have to deal with multiple registries. can the registries please get over the inter-registry rivalry and make life more reasonable for us, the paying members?
We currently have no cross-certification activity in member identity.
where as before i was merely inclined, this has just made me an extremely strong proponent of the isp web of trust identity model. randy
In message <17285.11841.343440.262334@roam.psg.com>, Randy Bush writes:
We are discussing how we can do subsidiary certificate services like this in APNIC but I think this goes outside of routing policy and into registry business practices which are unlikely to be common for all RIR and NIR in the ways that resource certificates *have* to be.
if it is not common across registries, and if my certs do not work across registries, then something is very very broken, and a major pita at the isps', aka your members', expense.
If you want to see member-certificates which gate access to RIR/NIR specific services common across all registries, I think you want to get that onto an RIR meeting agenda Randy.
i have been whining about the problems of cross-registry operation for over a decade, formally, informally, presos, ... i have had it on every rir's meeting agenda (except lacnic) for many years. do i need to iterate for every ort of service the registries provide?
we are the registries' customers. many of us, especially the ones who pay the registries the most, have to deal with multiple registries. can the registries please get over the inter-registry rivalry and make life more reasonable for us, the paying members?
We currently have no cross-certification activity in member identity.
where as before i was merely inclined, this has just made me an extremely strong proponent of the isp web of trust identity model.
I think the problem is both easier and harder than painted. First, you need a business agreement that you will accept each others' assertions of member identities, aka certificates. Second, you have to agree on a common format and meaning for certain fields, including thinks like CRLs. I'm not sure if I think the technical specs or the business agreement are the hard parts... --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
On Wed, 23 Nov 2005, Steven M. Bellovin wrote:
I think the problem is both easier and harder than painted. First, you need a business agreement that you will accept each others' assertions of member identities, aka certificates. Second, you have to agree on a common format and meaning for certain fields, including thinks like CRLs.
I'm not sure if I think the technical specs or the business agreement are the hard parts...
Ah the business issues start bubbling to the surface. Have you noticed for various reasons network service providers don't like to "sign" or "certify" the business activities of other entities. In the 1990's several network service providers (AT&T, BBN, etc) established PKIs, but now very few network service provider will "certify" S/MIME e-mail, SSL web, or other type of third-party activity. Although techincal folks may think its just about math, unfortunately some people think certificates and signatures mean more than just mathmatical formulas. I'm a bit confused why people think network service providers will be willing to "certify" transitive trust relationships about business relationships between third-parties.
On 25 nov 2005, at 02.07, Sean Donelan wrote:
Although techincal folks may think its just about math, unfortunately some people think certificates and signatures mean more than just mathmatical formulas. I'm a bit confused why people think network service providers will be willing to "certify" transitive trust relationships about business relationships between third-parties.
Given that ISPs even refuse or manipulate their AS objects to hide real peering or transit details for business reasons, getting them to sign certificates for these relationships might prove even harder... - kurtis -
At 17:06 -1000 11/23/05, Randy Bush wrote:
i have been whining about the problems of cross-registry operation for over a decade, formally, informally, presos, ... i have had it on every rir's meeting agenda (except lacnic) for many years. do i need to iterate for every ort of service the registries provide?
Sometimes I think you are right about this and sometimes I think you are wrong about this. It just may be that you are thinking only about the "right" half, but "operation" of the registry to some means the policy process too. Where I see this as "wrong" is: There are five distinct RIRs for a reason, to be attuned to local needs. The domain name industry has one "RIR" asserting authority and we see the political fallout of that. Having the five RIRs locked together would certainly benefit (usually the larger) organizations that deal across RIR boundaries, most likely (and I say that without certainty or accusation) to the detriment of smaller organizations tuned to the needs within one RIR. I think it's very important that we keep the policy processes - the decision making part, and even discussion - separate. Yes, that means it takes a long time to get a "global" (effectively, one involving IANA) policy through. On the other hand, you are "right" when it comes to the technical services rendered and the interfaces used. That's because the use of the data is global, no doubt about that. A student sending mail from Africa to Asia will traverse two or three RIR area networks, just to show how 1 consumer can cause a cross-RIR event. One of the dynamics I see happening now is that the RIRs are independently developing some advanced services. RIPE into DNSSEC, APNIC into certificates, LACNIC into IRIS and unifying the RIR WhoIs data. These advancements happen locally much faster than globally, as is true with any innovation. "Failed" attempts at advancement will be easier to recover from too. Eventually we want these services to be global, but in development I expect differences.
we are the registries' customers. many of us, especially the ones who pay the registries the most, have to deal with multiple registries. can the registries please get over the inter-registry rivalry and make life more reasonable for us, the paying members?
Keep in mind that the RIRs were originally cobbled together out of different cloth. Unifying the service interface will take an investment in doing that. This is why I have made comments at ARIN meetings about providing technical input to ARIN - trying to define a way to have the community, or even just the membership, inform ARIN on what service interfaces we would like to see in an open, reviewable arena. ARIN has this for policies, but the path towards service upgrades is not as well defined. It's one thing to lay heat at the feet of organizations, it's another to make clear the reason for the heat.
where as before i was merely inclined, this has just made me an extremely strong proponent of the isp web of trust identity model.
The upside of this is that it directly addresses the routing problem - ISPs get to determine who they trust for the data they rely on. On the other hand, ultimately a web of trust has to fair to newcomers, not rely on superficial "popularity", and obviously scaleable. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store.
On 24 nov 2005, at 03.54, George Michaelson wrote:
If you want to see member-certificates which gate access to RIR/NIR specific services common across all registries, I think you want to get that onto an RIR meeting agenda Randy.
We currently have no cross-certification activity in member identity.
I was arguing for this when RIPE was introducing the X.509 auth for the LIR portal. And I clearly remember multi-RIR customers asking for the same thing for exactly the same reason (I think it was Nigel and Neil), as was Randy. So it's certainly been on the agenda... - kurtis -
participants (8)
-
Edward Lewis -
George Michaelson -
Kurt Erik Lindqvist -
Randy Bush -
Sandy Murphy -
Sean Donelan -
Steven M. Bellovin -
william(at)elan.net