X.509 authentication in the RIPE Database
Dear Colleagues, [Apologies for duplicate e-mails] As previously discussed in RIPE 44 and 45, please find below the proposal to add X.509 authentication to the RIPE Database. ******************************************************************** X.509 Certificate Authentication in the RIPE Database 0. Objective To make a new method of authentication available using X.509 certificates. 1. Motivation The RIPE Database currently has 5 methods of authentication, none of these are completely satisfactory with regard to security, standards support (de facto and de jure), pervasiveness and integration. The X.509 authentication mechanism would satisfy all of these factors: 1. Security: X.509 allows for the use of digital signatures, making it unnecessary to send clear passwords via e-mail. The current PGP authentication also provides this feature. 2. Standards support: X.509 is an ISO standard and is the only mechanism supported by mailers and clients used in more than 90% of communications with the RIPE NCC. 3. Pervasiveness: X.509 can be utilised with several communication mechanisms, not only mail. A common example is SSL/HTTPS. No other authentication mechanism is as strong and easily available with the web. 4. Integration: This authentication method will integrate seamlessly with the general framework of security in use at the RIPE NCC. It is also important to note that, the general trend among the other Regional Internet Registries (RIRs) is the use of X.509 as a main authentication method. 2. User visible changes a. Requirements To be able to the X.509 authentication method the user requires a certificate issued through the RIPE NCC LIR portal. Information on how to obtain a certificate can be found at: http://lirportal.ripe.net/lirportal/faq/pki.html Therefore the X.509 method would only be available to LIRs. This can be changed if the community so desires. b. Maintainers The auth: attribute of the mntner object will have a new authentication scheme, X509. The parameter will be a Distinguished Name (DN) according to RFC 2253. There is an important fundamental difference between PGP authentication and X.509; the database does not need a key-cert object for X.509 certificates, the DN has to be trusted. This means the certificate must be signed by a trusted authority and that self-signed certificates will not be accepted. The trusted authority will be the RIPE NCC Certificate Authority that is currently only available to LIRs. Following is an example of a maintainer with X.509 authentication: mntner: RIPE-DBM-MNT descr: Mntner for RIPE DBM objects. admin-c: AMR68-RIPE tech-c: RD132-RIPE upd-to: ripe-dbm@ripe.net mnt-nfy: ripe-dbm@ripe.net auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=eu.ripe.dbm notify: ripe-dbm@ripe.net mnt-by: RIPE-DBM-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm@ripe.net 20030617 source: RIPE For users the only variable part within the new auth: attribute is the CN (Common Name). c. Submitting updates via e-mail Updates for objects maintained by a maintainer with X509 authentication must be sent in S/MIME format and signed (not encrypted) using the private key associated with the issued certificate. This key must also be made available to the mailer. Users that have a mail user agent that does not support S/MIME might consider using OpenSSL S/MIME facilities to prepare their mails. d. Submitting updates via webupdates Webupdates will accept client-side certificates. This means that the strongest type of authentication possible will be easily available for users using the web. For this to be possible the certificate and private key have to be loaded in the user browser.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tiago,
It is also important to note that, the general trend among the other Regional Internet Registries (RIRs) is the use of X.509 as a main authentication method.
when you say that the trend among the other RIRs is to go for X.509 certificates, could you please elaborate on what they are doing and how far they are? Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPwUlAqarNKXTPFCVEQJeCgCgxNCsFZmt7Xcw8ob7EQwE1a5km34AoNMe jvMNyhJIE0LxI6nuZzrwv+Df =HD+6 -----END PGP SIGNATURE-----
-----Original Message----- From: db-wg-admin@ripe.net [mailto:db-wg-admin@ripe.net] On Behalf Of Kurt Erik Lindqvist Sent: Friday, 4 July 2003 4:56 PM To: ripe-dbm@ripe.net Cc: ncc-services-wg@ripe.net; db-wg@ripe.net Subject: [db-wg] Re: [ncc-services-wg] X.509 authentication in the RIPE Database
Tiago,
It is also important to note that, the general trend among
the other
Regional Internet Registries (RIRs) is the use of X.509 as a main authentication method.
when you say that the trend among the other RIRs is to go for X.509 certificates, could you please elaborate on what they are doing and how far they are?
Best regards,
- - kurtis -
Hi all, In APNIC we use X.509 certificate to secure MyAPNIC (similar to LIR Portal). Having X.509 auth in the whois db would make a better integration with this facility. We have also been closely monitoring IETF's PKIX working group where there's an effort to certify ASN and internet addresses to protect routing announcements. This might eventually affect how the public will use the internet routing registry, which is also part or our whois database. We expect X.509 will be used to make certified statements about resource allocation as part of S-BGP or SO-BGP and/or wider requirements for authoritative statements on resources Hope this helps. Cheers, Sanjaya ______________________________________________________________________ Senior Project Manager <sanjaya@apnic.net> Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 ---------------------------------------------------------------------- See you at APNIC 16 Seoul, Korea, 19-22 August 2003 http://www.apnic.net/meetings ----------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
It is also important to note that, the general trend among the other Regional Internet Registries (RIRs) is the use of X.509 as a main authentication method.
when you say that the trend among the other RIRs is to go for X.509 certificates, could you please elaborate on what they are doing and how far they are?
Best regards,
- - kurtis -
Hi all,
In APNIC we use X.509 certificate to secure MyAPNIC (similar to LIR Portal). Having X.509 auth in the whois db would make a better integration with this facility.
Is this then being widely used? No issues with client support and configurations?
We have also been closely monitoring IETF's PKIX working group where there's an effort to certify ASN and internet addresses to protect routing announcements. This might eventually affect how the public will use the internet routing registry, which is also part or our whois database.
We expect X.509 will be used to make certified statements about resource allocation as part of S-BGP or SO-BGP and/or wider requirements for authoritative statements on resources
I am not following the PKIX WG. Do you have any links to information on this, or how this is planned to be implemented? Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPxEc86arNKXTPFCVEQJ6RgCfT1H27hyWfZ2c3QYjuHY0QE5E48kAoJ1j AFFT7gAO1mxCPUQwj8fJnzSZ =4tDj -----END PGP SIGNATURE-----
In APNIC we use X.509 certificate to secure MyAPNIC (similar to LIR Portal). Having X.509 auth in the whois db would make a better integration with this facility.
Is this then being widely used? No issues with client support and configurations?
Hi Kurtis, We have about 450 certificates issued so far. On Windows platform client support works fine for all browsers (IE, Netscape, Opera, Mozilla). OS-X is ok with Netscape and Opera (Opera in OS-X has some problems in handling .css, but that's not X.509 related). Linux is fine with Netscape and Mozilla. The hardest thing is to get the requestor to send their photo-id! :-) which is required by our Certificate Practice Statement.
We have also been closely monitoring IETF's PKIX working group where there's an effort to certify ASN and internet addresses to protect routing announcements. This might eventually affect how the public will use the internet routing registry, which is also part or our whois database.
We expect X.509 will be used to make certified statements about resource allocation as part of S-BGP or SO-BGP and/or wider requirements for authoritative statements on resources
I am not following the PKIX WG. Do you have any links to information on this, or how this is planned to be implemented?
For the PKIX draft see: http://www.ietf.org/internet-drafts/draft-ietf-pkix-x509-ipaddr-as-extn- 01.txt On S-BGP check this site: http://www.ir.bbn.com/projects/sbgp/ On SoBGP: ftp://ftp-eng.cisco.com/sobgp/index.html Some comments on soBGP/sBGP: http://www.psg.com/~randy/030603.nanog-sxbgp.pdf http://www.nanog.org/mtg-0306/pdf/meyer.pdf Hope this helps. Cheers, Sanjaya
Best regards,
- - kurtis -
On söndag, jul 13, 2003, at 10:48 Europe/Stockholm, Kurt Erik Lindqvist wrote:
In APNIC we use X.509 certificate to secure MyAPNIC (similar to LIR Portal). Having X.509 auth in the whois db would make a better integration with this facility.
Is this then being widely used? No issues with client support and configurations?
Do you have your own root-CA, or do you use someone else? If you have your own, how do you distribute the certificate? paf
On söndag, jul 13, 2003, at 10:48 Europe/Stockholm, Kurt Erik Lindqvist wrote:
In APNIC we use X.509 certificate to secure MyAPNIC (similar to LIR Portal). Having X.509 auth in the whois db would make a better integration with this facility.
Is this then being widely used? No issues with client support and configurations?
Do you have your own root-CA, or do you use someone else? If you have your own, how do you distribute the certificate?
paf
Hi Patrik, Yes we run our own root-CA, and the first step is for the client to install APNIC root CA in its trusted root store. We're using the OpenCA software (www.openca.org) and modify it to suit our purpose. When we issue a certificate, an e-mail containing download url + instruction is sent to the requestor. Cheers, Sanjaya
On måndag, jul 14, 2003, at 02:53 Europe/Stockholm, Sanjaya wrote:
Yes we run our own root-CA, and the first step is for the client to install APNIC root CA in its trusted root store.
Good.
We're using the OpenCA software (www.openca.org) and modify it to suit our purpose. When we issue a certificate, an e-mail containing download url + instruction is sent to the requestor.
...which imply each customer/user of yours have to get a certificate from you which they are to use in the communication with you? paf
We're using the OpenCA software (www.openca.org) and modify it to suit our purpose. When we issue a certificate, an e-mail containing download url + instruction is sent to the requestor.
...which imply each customer/user of yours have to get a certificate from you which they are to use in the communication with you?
paf
Yes, that is correct. Cheers, Sanjaya
On Mon, 14 Jul 2003 07:47:11 +0200 Patrik Fältström <paf@cisco.com> wrote:
On måndag, jul 14, 2003, at 02:53 Europe/Stockholm, Sanjaya wrote:
Yes we run our own root-CA, and the first step is for the client to install APNIC root CA in its trusted root store.
Good.
We're using the OpenCA software (www.openca.org) and modify it to suit our purpose. When we issue a certificate, an e-mail containing download url + instruction is sent to the requestor.
...which imply each customer/user of yours have to get a certificate from you which they are to use in the communication with you?
paf
Yes. There are open questions here, about capabilities in the wider community to understand PKI, and also about the nature of certification: right now we are only doing identity certificates for people, but we are using them to gateway access into I.T. Systems, which makes them agents for authorization as well as authentication. They are being presented to SSL enabled webservers, which then use the identity knowledge to decide to enable/permit a privileged operation like a whois object update. Right now, the APNIC model has stored tokens in the web database backend, but we'd expect that we could bypass those, if we took the PKI model all the way to the whois. When we discuss PKIX, and things like S-BGP or SO-BGP, it introduces questions about how we will tie certificates to resources, what are the properties of the certificate we need to play with to represent the resource, how 'unitary' are these assertions or can they authenticate a range, and bless instances of the sub-range as well.. This is an area we are going to need to discuss widely. The Lynn/Kent/Seo draft on X.509 Address and AS identifiers in certificates is the first document I've seen coming from the IETF which treads into this area and I think the RIR community needs to review and participate in this discussion. draft-ietf-pkix-x509-ipaddr-as-extn-01.txt cheers -George -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net
I have spent some time _talking_ with people about this project, so now I am not guessing anymore. What was told me makes perfect sense, but doesn't really match the message sent out. First of all, my fear when reading the message was that one thought S/MIME was perfect, working, etc etc and this in turn would make X.509 possible to use both in email and for http/ssl. What I now heard was that the ssl connections will be strengthened by adding client side certificates which can be used for authentication. This might of course rise questions about the use of third-party-CA for the certificates, but this is (as clarified in this mail below) resolved by having the RIR being an CA by itself. This gives authenticated and secure connections between the RIR and the customer/member, as long as the certificate format issues are resolved (which should not be hard). Now, give we have this certificate which creates the trust relationship between the RIR (which also is the CA) and the client, we _MIGHT_ be able to also use it for other things. For example, if one is lucky, we can use it for signing email if the email client can use the same client certificate. Note that this last paragraph is the part of X.509 where my experience says there is a big difference between the map and the reality, *NOT* the main reason why this project is running -- strengthened authentication/security when using "the web" for access to the databases. paf On måndag, jul 14, 2003, at 11:15 Europe/Stockholm, George Michaelson wrote:
On Mon, 14 Jul 2003 07:47:11 +0200 Patrik Fältström <paf@cisco.com> wrote:
On måndag, jul 14, 2003, at 02:53 Europe/Stockholm, Sanjaya wrote:
Yes we run our own root-CA, and the first step is for the client to install APNIC root CA in its trusted root store.
Good.
We're using the OpenCA software (www.openca.org) and modify it to suit our purpose. When we issue a certificate, an e-mail containing download url + instruction is sent to the requestor.
...which imply each customer/user of yours have to get a certificate from you which they are to use in the communication with you?
paf
Yes.
There are open questions here, about capabilities in the wider community to understand PKI, and also about the nature of certification: right now we are only doing identity certificates for people, but we are using them to gateway access into I.T. Systems, which makes them agents for authorization as well as authentication. They are being presented to SSL enabled webservers, which then use the identity knowledge to decide to enable/permit a privileged operation like a whois object update. Right now, the APNIC model has stored tokens in the web database backend, but we'd expect that we could bypass those, if we took the PKI model all the way to the whois.
When we discuss PKIX, and things like S-BGP or SO-BGP, it introduces questions about how we will tie certificates to resources, what are the properties of the certificate we need to play with to represent the resource, how 'unitary' are these assertions or can they authenticate a range, and bless instances of the sub-range as well.. This is an area we are going to need to discuss widely.
The Lynn/Kent/Seo draft on X.509 Address and AS identifiers in certificates is the first document I've seen coming from the IETF which treads into this area and I think the RIR community needs to review and participate in this discussion.
draft-ietf-pkix-x509-ipaddr-as-extn-01.txt
cheers -George
-- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net
What I now heard was that the ssl connections will be strengthened by adding client side certificates which can be used for authentication. This might of course rise questions about the use of third-party-CA for the certificates, but this is (as clarified in this mail below) resolved by having the RIR being an CA by itself.
so i am supposed to install the RIRs' certs in my browser as root CAs and ignore the big hole for attack this opens? i already *remove* a bunch of root CAs when i bring up a new browser. this is the new internet. get paranoid. let the RIRs spend a few of the bucks they have getting their certs signed by a well-trusted root CA. randy
On onsdag, jul 16, 2003, at 16:28 Europe/Stockholm, Randy Bush wrote:
so i am supposed to install the RIRs' certs in my browser as root CAs and ignore the big hole for attack this opens? i already *remove* a bunch of root CAs when i bring up a new browser. this is the new internet. get paranoid.
let the RIRs spend a few of the bucks they have getting their certs signed by a well-trusted root CA.
It all depends on who you trust. If I personally am to communicate with someone, I want to have that other party give me via in-real-life-communication his fingerprint for his PGP key (and vice versa). Then we have the trust relationship needed. I can further in all PGP implementations I have seen say "I do _NOT_ trust this other party as one which introduces others (I trust him, but not keys he sign). I have not seen you can do that with X.509/SSL. This which Randy point out is very important, as with X.509 you always need a third party. There are good reason why the RIR should get their cert from a "real" CA, but then both the RIR and the customer need to trust this third party. Do we trust the third party more than the RIR? paf
Do we trust the third party more than the RIR? ^ as a root CA
there i things for which i trust RIRs, some for which i trust vendors, some for which i trust Thawte, some for which i trust my dogs, and some for which i trust no one. as root CAs, i do not trust the RIRs as much as i trust a few others. randy
On onsdag, jul 16, 2003, at 16:41 Europe/Stockholm, Randy Bush wrote:
Do we trust the third party more than the RIR? ^ as a root CA
Yes, sorry. This is of course very important. paf
there i things for which i trust RIRs, some for which i trust vendors, some for which i trust Thawte, some for which i trust my dogs, and some for which i trust no one.
as root CAs, i do not trust the RIRs as much as i trust a few others.
randy
On Wed, 16 Jul 2003, Randy Bush wrote:
so i am supposed to install the RIRs' certs in my browser as root CAs and ignore the big hole for attack this opens? i already *remove* a bunch of root CAs when i bring up a new browser. this is the new internet. get paranoid.
I might overlook something but what's the big hole (apart from the obvious fact that importing the trustanchor needs some out-of-band support)?
let the RIRs spend a few of the bucks they have getting their certs signed by a well-trusted root CA.
From a trust point of view it is in fact *better* to consciously import
Specify 'few'. As far as I know this it is not cheap to have your PKI signed by one of the 'well-trusted' root CAs. Or are you suggesting that RIPE should select one of the commercial root CAs and get all the client certificates from that shop? the RIPE root-ca certificate in your browser then to simply trust what's in your root certificate store. Jan
so i am supposed to install the RIRs' certs in my browser as root CAs and ignore the big hole for attack this opens? i already *remove* a bunch of root CAs when i bring up a new browser. this is the new internet. get paranoid. I might overlook something but what's the big hole
someone getting at the root CA key at an RIR
Specify 'few'. As far as I know this it is not cheap to have your PKI signed by one of the 'well-trusted' root CAs.
maybe not cheap for a student, but an RIR can afford it
Or are you suggesting that RIPE should select one of the commercial root CAs and get all the client certificates from that shop?
no, the RIRs can sign their customers certs. maybe a tutorial is needed on how this stuff works. paf, is there one readily available?
From a trust point of view it is in fact *better* to consciously import the RIPE root-ca certificate in your browser then to simply trust what's in your root certificate store.
when the RIRs' procedures to protect their root CA keys are audited by third parties who have the expertise to do so. randy
On onsdag, jul 16, 2003, at 16:51 Europe/Stockholm, Randy Bush wrote:
Or are you suggesting that RIPE should select one of the commercial root CAs and get all the client certificates from that shop?
no, the RIRs can sign their customers certs.
maybe a tutorial is needed on how this stuff works. paf, is there one readily available?
Well, the problem is to know whether the tutorial talk about how the map is drawn or how things work in reality. The overall question is how to build the chain of trust in X.509. We can do (a) CA -> RIR -> RIR member (b) CA -> RIR and CA -> RIR member As I don't work in the X.509 environment (I have been running my head against the wall too many times when discovering the applications do not do everything magic the spec is supposed to support) I am the wrong person to ask. BUT, I can find someone which can help.
From a trust point of view it is in fact *better* to consciously import the RIPE root-ca certificate in your browser then to simply trust what's in your root certificate store.
when the RIRs' procedures to protect their root CA keys are audited
...and the question is whether this audit and operations is cheaper than to "just buy the thing" from a different CA... paf
On Wednesday, Jul 16, 2003, at 16:51 Europe/Amsterdam, Randy Bush wrote:
ok something but what's the big hole
someone getting at the root CA key at an RIR
There would still be the very similar issue of someone getting at the certificate that the RIR bought from the third party CA. In reality, you do not need to have the RIRs sign any of the customer certificates, they simply need to verify that the certificate presented by the member does indeed belong to the member and incorporate it into the RIR system. If the RIR was a root CA then it could issue certificates to its members for a fee agreed by the membership (potentially zero). In any case, I believe external certificates should allowed to be used in the system so that people who do not trust the RIR CA can get their certificate somewhere else. A user can also choose to control the scope of validity of an RIR issued certificate by defining the scope in the browser if it allows it or having a second installation of the browser used only for the purpose of communication with the RIR,. Joao
someone getting at the root CA key at an RIR There would still be the very similar issue of someone getting at the certificate that the RIR bought from the third party CA.
no, as that would not be installed in my browser to be absolutely trusted. randy
On torsdag, jul 17, 2003, at 13:48 Europe/Stockholm, Randy Bush wrote:
someone getting at the root CA key at an RIR There would still be the very similar issue of someone getting at the certificate that the RIR bought from the third party CA.
no, as that would not be installed in my browser to be absolutely trusted.
A friend explained it like this (more people on this list might know Dirk-Willem van Gulik). paf
You do have to separate completely the server->client auth and the client->server auth; they do not really over lap; though are rather identical; and traditionally shared certs. But do not have to.
I.e.
o The web server _may_ have a cert A.
A may be signed by A or by B.
o The browser talks to the web server. It may check that A is on a list of cert's it trusts; or that A is signed by a cert which is on a list of cert's its trust. Such as 'B'. And so on up the chain. Until it runs out or finds a cert it trusts.
o A user _may_ have a cert C1.
o That cert may be signed by C1 or by D.
o A web server can deceide to ONLY allow access to people which have a cert it has on a list (i.e. C1, C2, C3.. ) or those that are signed by a cert on a list (D, ..) and so on up the chain. And perhaps check it is still valid time wise and not on a revocation list.
At any point it is _easier_ if they all end up being signed by some root CA; as then you do not have to keep your own long lists (A, C1, C2, C3) about all the servers and clients you trust on either side. And as a user you just need a few root CA's.
I.e. in the web server you need to configure
-> your own cert pub and private
-> and add all the pub's in your signing chain up to the top (as in the SSL protocol you may be asked for them by the client).
And in order to check your clients you need
-> A (list of) cert you trust, i.e. the C1..C4 or a cert which signed C1..C4 or higher up.
-> And perhaps valid/revoc lists.
Likewise on the client side you need to keep
-> A list of all the root CA's you ultimately trust.
-> Your own client cert
-> and all certs up the chain as oyu may be asked for it.
But ultimately and over time; some of your root CA's go bad; so a user needs to remove them from his browser list; and ultimately you need to revocate so you need to keep some sort of admin lists of C1, C2.. etc.
On Thursday, Jul 17, 2003, at 13:48 Europe/Amsterdam, Randy Bush wrote:
someone getting at the root CA key at an RIR There would still be the very similar issue of someone getting at the certificate that the RIR bought from the third party CA.
no, as that would not be installed in my browser to be absolutely trusted.
If the certificate that signs other certificates is compromised, the trust in the signed certificates is gone because you won't be able to know if new certificates have been generated by non-legitimate parties. Joao
Hi all, APNIC has a "terms and conditions" but it is not yet a formal CPS. We are working on that. We also have investigated cross-certification from a well known commercial CA on February this year. However, the quoted price of US$50,000 a year is not justified in our opinion. We are also considering a formal audit once our CPS has been formalised. Please note that at present our certificates are used for identifying member staff to access internal aplication (MyAPNIC), so the subject of third-party trust issues may not yet apply. By the time 3rd parties become involved (eg allocation/route certification), we would certainly have more standard CA/PKI structures in place. This is a new area for most of us, and we are very open to advice and input from the community. Cheers, Sanjaya APNIC CA Project Manager
-----Original Message----- From: db-wg-admin@ripe.net [mailto:db-wg-admin@ripe.net] On Behalf Of Randy Bush Sent: Thursday, 17 July 2003 12:52 AM To: Jan Meijer Cc: Patrik Fältström; ncc-services-wg@ripe.net; db-wg@ripe.net Subject: Re: [db-wg] Re: [ncc-services-wg] X.509 authentication in the RIPE Database
so i am supposed to install the RIRs' certs in my browser as root CAs and ignore the big hole for attack this opens? i already *remove* a bunch of root CAs when i bring up a new browser. this is the new internet. get paranoid. I might overlook something but what's the big hole
someone getting at the root CA key at an RIR
Specify 'few'. As far as I know this it is not cheap to have your PKI signed by one of the 'well-trusted' root CAs.
maybe not cheap for a student, but an RIR can afford it
Or are you suggesting that RIPE should select one of the commercial root CAs and get all the client certificates from that shop?
no, the RIRs can sign their customers certs.
maybe a tutorial is needed on how this stuff works. paf, is there one readily available?
From a trust point of view it is in fact *better* to consciously import the RIPE root-ca certificate in your browser then to simply trust what's in your root certificate store.
when the RIRs' procedures to protect their root CA keys are audited by third parties who have the expertise to do so.
randy
% Please note that at present our certificates are used for identifying % member staff to access internal aplication (MyAPNIC), so the subject of % third-party trust issues may not yet apply. By the time 3rd parties % become involved (eg allocation/route certification), we would certainly % have more standard CA/PKI structures in place. % % This is a new area for most of us, and we are very open to advice and % input from the community. % % Cheers, % Sanjaya % APNIC CA Project Manager of interest to me is the presumption that all interaction between parties is assumed to be via http applications, e.g. the need to install a cert into your browser. last time I checked, many/most RIRs supported a variety of methods for interaction w/ their customers. I'd like to see how the use of x509 certs would be applicable/palatable to other applications. It would be useful to also have more clarification on how bootstraping is to be done. I tend to chnage hardware/software every 6 months or so and have a tough time keeping up w/ all the existing pswds/keys that the various systems use/expect. I will forget/lose any pswd/key at least once. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).
Bill Manning wrote:
% Please note that at present our certificates are used for identifying % member staff to access internal aplication (MyAPNIC), so the subject of % third-party trust issues may not yet apply. By the time 3rd parties % become involved (eg allocation/route certification), we would certainly % have more standard CA/PKI structures in place. % % This is a new area for most of us, and we are very open to advice and % input from the community. % % Cheers, % Sanjaya % APNIC CA Project Manager
of interest to me is the presumption that all interaction between parties is assumed to be via http applications, e.g. the need to install a cert into your browser.
last time I checked, many/most RIRs supported a variety of methods for interaction w/ their customers. I'd like to see how the use of x509 certs would be applicable/palatable to other applications.
Existing access methods will be unaffected by the RIPE NCC's adoption of X.509 technology to interact with our members (LIRs). We do expect that people will make heavy use of HTTP/SSL because of the ease of use it offers. For a review of the planned changes to the various ways that the LIRs and the RIPE NCC interact, please have a look at section 3 of this document: http://www.ripe.net/ripe/draft-documents/pki-20030429.html
It would be useful to also have more clarification on how bootstraping is to be done.
Briefly, LIRs can obtain a certificate from the LIR Portal: https://lirportal.ripe.net/ They must first have obtained an account, through the existing procedures, documented here: https://lirportal.ripe.net/lirportal/activation/activation_request.html This is explained in the PKI document, at the URL given above.
I tend to chnage hardware/software every 6 months or so and have a tough time keeping up w/ all the existing pswds/keys that the various systems use/expect. I will forget/lose any pswd/key at least once.
One of the reasons X.509 was chosen is because it will allow LIRs to use one authentication mechanism for accessing all RIPE NCC services. This would help reduce the number of passwords or keys you need to keep track of. However, the timeline for adopting such methods is strictly up to the users - you can use current techniques until you find it beneficial for you to change the procedures on your side. The RIPE Database supports many authentication mechanisms today, NONE, passwords hashed with DES or MD5, as well as PGP. It used to support using sender e-mail as authentication, but this was removed by community request. Likewise the community has proposed removing NONE authentication, and this project will move forward. These efforts are separate from this project, however. -- Shane Kerr RIPE NCC
let the RIRs spend a few of the bucks they have getting their certs signed by a well-trusted root CA.
Is there such a thing? I can't think of a "well-known" root CA I'd trust farther than I could throw it. (It's not entirely clear to me what these would be used for. What I've seen leads me to think this is for some SSLified Web horror, in which case the obvious answer is surely to just tell your client software to trust that root cert only for connections to the relevant RIR's pages, preferably with active _dis_trust for other connections.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Randy, Randy Bush wrote:
What I now heard was that the ssl connections will be strengthened by adding client side certificates which can be used for authentication. This might of course rise questions about the use of third-party-CA for the certificates, but this is (as clarified in this mail below) resolved by having the RIR being an CA by itself.
so i am supposed to install the RIRs' certs in my browser as root CAs and ignore the big hole for attack this opens? i already *remove* a bunch of root CAs when i bring up a new browser. this is the new internet. get paranoid.
let the RIRs spend a few of the bucks they have getting their certs signed by a well-trusted root CA.
Certificates from the RIPE NCC's CA are not intended for 3rd party authentication. They are only intended to allow the LIRs to authenticate themselves to the RIPE NCC. Some mail clients require that the RIPE NCC CA be installed as a root CA before they will let the user send mail signed by a certificate issued by the RIPE NCC CA. Therefore we provide an easy means for users to do this. If you wish to use a mail client without this restriction, there is no reason to trust the RIPE NCC's CA for anything other than issuing your certificate. It's not certificates for the RIPE NCC that are the issue here, it's certificates for the LIRs, to be trusted by the RIPE NCC. If the RIPE NCC were to trust certificates issued by another CA, then we would be relying on their registration authority (RA). Not only would the RIPE NCC have to trust a 3rd party to identify RIPE NCC members, but users would need to provide a separate set of documentation and probably also pay a fee to obtain their certificates. -- Shane Kerr RIPE NCC
On Mon, 2003-07-14 at 05:15, George Michaelson wrote:
On Mon, 14 Jul 2003 07:47:11 +0200 Patrik Fältström <paf@cisco.com> wrote:
On måndag, jul 14, 2003, at 02:53 Europe/Stockholm, Sanjaya wrote:
Yes we run our own root-CA, and the first step is for the client to install APNIC root CA in its trusted root store.
Good.
We're using the OpenCA software (www.openca.org) and modify it to suit our purpose. When we issue a certificate, an e-mail containing download url + instruction is sent to the requestor.
...which imply each customer/user of yours have to get a certificate from you which they are to use in the communication with you?
paf
Yes.
There are open questions here, about capabilities in the wider community to understand PKI, and also about the nature of certification: right now we are only doing identity certificates for people, but we are using them to gateway access into I.T. Systems, which makes them agents for authorization as well as authentication. They are being presented to SSL enabled webservers, which then use the identity knowledge to decide to enable/permit a privileged operation like a whois object update. Right now, the APNIC model has stored tokens in the web database backend, but we'd expect that we could bypass those, if we took the PKI model all the way to the whois.
When we discuss PKIX, and things like S-BGP or SO-BGP, it introduces questions about how we will tie certificates to resources, what are the properties of the certificate we need to play with to represent the resource, how 'unitary' are these assertions or can they authenticate a range, and bless instances of the sub-range as well.. This is an area we are going to need to discuss widely.
The Lynn/Kent/Seo draft on X.509 Address and AS identifiers in certificates is the first document I've seen coming from the IETF which treads into this area and I think the RIR community needs to review and participate in this discussion.
draft-ietf-pkix-x509-ipaddr-as-extn-01.txt
cheers -George
The following Internet Draft was published a few weeks ago -- http://www.ietf.org/internet-drafts/draft-weis-sobgp-certificates-00.txt It employs a "web of trust" model. The exact role of the RIR community under this model seems to be somewhat murky. -Larry Blunk
participants (4)
-
Bill Manning -
der Mouse -
George Michaelson -
Jan Meijer -
Joao Damas -
Joao Damas -
Kurt Erik Lindqvist -
Larry J. Blunk -
Patrik Fältström -
Randy Bush -
Sanjaya -
Shane Kerr -
Tiago Antao