X.509 authentication in the RIPE Database, take II
All, [Apologies for duplicate e-mails] Attached please find a proposal for X.509 authentication in the RIPE Database. From the Database point of view (that is, syntax and semantics), it is the same as the one sent 3 July 2003. The difference is that it contains only the specific details of the change, in a straightforward fashion. I hope that we have addressed questions about the use of X.509 that arose in earlier discussions. -- Shane Kerr RIPE NCC Addition of X.509 authentication to the Database Proposal: To add an X509 authentication type to the "auth:" attribute. Attributes with this type will use the Distinguished Name (DN) of the certificate to identify it. Motivation: X.509 allows a single authentication method to work for both e-mail and the web. LIRs can receive an X.509 certificate through the LIR Portal, and should be able to use this to update records they control in the Database. X.509 is "strong", like PGP, although a different trust model is used. Details: The "auth:" attribute of the mntner class will have a new authentication scheme, X509. The DN, as defined in RFC 2253, will be used to identify the specific certificate used. Note that there is no key-cert object for the X509 scheme. Instead, the certificate must be signed by a trusted authority. The trusted authority will be the RIPE NCC Certificate Authority (CA) that is currently only available to LIRs. It is possible to configure additional CAs in future, should this become desirable. For instance, existing commercial CAs could be allowed, or the RIPE NCC could create a CA to issue certificates to non-LIRs for this purpose only. Below is an example of a maintainer with X.509 authentication: mntner: EXAMPLE-MNT descr: Sample maintainer for example. admin-c: SWK1-RIPE tech-c: RD132-RIPE tech-c: HOHO-RIPE upd-to: ripe-dbm@ripe.net mnt-nfy: ripe-dbm@ripe.net auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user1 auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user2 notify: ripe-dbm@ripe.net mnt-by: EXAMPLE-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm@ripe.net 20030813 source: RIPE Usage: 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. Synchronous updates for objects maintained by a maintainer with X509 authentication must use an SSL connection using the private key from the issued certificate on the client side. Web updates for objects maintained by a maintainer with X509 authentication can use a browser with the certificate loaded. The web updates screens will allow users to specify that they want to identify themselves using the client-side private key, over an SSL connection.
Shane, adding a new strong authentication method to the Database, is in my own personal opinion, a good thing(tm), particularly if the same credential can be used for other interactions with the RIPE NCC, make user's life easier. I wonder however about a few questions: - will this auth method be available only to RIPE NCC members? Is it not seen as a valuable general addition for non-member users of the IRR part of the RIPE DB? - Why the choice of not publishing the pulic part of the certificated in the DB? The choice to have a key-cert for the PGP method was not to do with issues of web of trust but rather for purposes of helping the users with their data maintenance. As a matter of fact the recommendation regarding the use of PGP in the RIPE DB, as described in the RFC and the minutes of the DBSEC TF, was to use a PGP key for this purpose that was not used elsewhere. - will the RIPE NCC make avaiable, at the time of implementation, documentation to guide use of this feature by users with a couple of the most popular clients? Thanks for the good work, Joao Damas On Thursday, August 14, 2003, at 06:24 PM, Shane Kerr wrote:
All,
[Apologies for duplicate e-mails]
Attached please find a proposal for X.509 authentication in the RIPE Database. From the Database point of view (that is, syntax and semantics), it is the same as the one sent 3 July 2003. The difference is that it contains only the specific details of the change, in a straightforward fashion.
I hope that we have addressed questions about the use of X.509 that arose in earlier discussions.
-- Shane Kerr RIPE NCC Addition of X.509 authentication to the Database
Proposal:
To add an X509 authentication type to the "auth:" attribute. Attributes with this type will use the Distinguished Name (DN) of the certificate to identify it.
Motivation:
X.509 allows a single authentication method to work for both e-mail and the web. LIRs can receive an X.509 certificate through the LIR Portal, and should be able to use this to update records they control in the Database. X.509 is "strong", like PGP, although a different trust model is used.
Details:
The "auth:" attribute of the mntner class will have a new authentication scheme, X509. The DN, as defined in RFC 2253, will be used to identify the specific certificate used.
Note that there is no key-cert object for the X509 scheme. Instead, the certificate must be signed by a trusted authority. The trusted authority will be the RIPE NCC Certificate Authority (CA) that is currently only available to LIRs. It is possible to configure additional CAs in future, should this become desirable. For instance, existing commercial CAs could be allowed, or the RIPE NCC could create a CA to issue certificates to non-LIRs for this purpose only.
Below is an example of a maintainer with X.509 authentication:
mntner: EXAMPLE-MNT descr: Sample maintainer for example. admin-c: SWK1-RIPE tech-c: RD132-RIPE tech-c: HOHO-RIPE upd-to: ripe-dbm@ripe.net mnt-nfy: ripe-dbm@ripe.net auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user1 auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user2 notify: ripe-dbm@ripe.net mnt-by: EXAMPLE-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm@ripe.net 20030813 source: RIPE
Usage:
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.
Synchronous updates for objects maintained by a maintainer with X509 authentication must use an SSL connection using the private key from the issued certificate on the client side.
Web updates for objects maintained by a maintainer with X509 authentication can use a browser with the certificate loaded. The web updates screens will allow users to specify that they want to identify themselves using the client-side private key, over an SSL connection.
Joao, Joao Luis Silva Damas wrote:
adding a new strong authentication method to the Database, is in my own personal opinion, a good thing(tm), particularly if the same credential can be used for other interactions with the RIPE NCC, make user's life easier.
I wonder however about a few questions:
- will this auth method be available only to RIPE NCC members? Is it not seen as a valuable general addition for non-member users of the IRR part of the RIPE DB?
Initially it will only be available for RIPE NCC members. There are three ways we could extend the service to non-LIRs: 1. Accept certificates from certain "well-known" CAs, for example Thawte, Verisign, etc. 2. Issue certificates from a RIPE NCC CA established for this purpose, and accept them. 3. Accept all certificates, including self-signed certificates. #1 is relatively easy - the main overhead would be maintaining the Certificate Revokation Lists from the CAs. Deciding which CAs to support may also be tricky. #2 is also relatively easy, since we already have the technology. #3 is more difficult, and would require a slight change of the design, and administration issues (see below).
- Why the choice of not publishing the pulic part of the certificated in the DB? The choice to have a key-cert for the PGP method was not to do with issues of web of trust but rather for purposes of helping the users with their data maintenance. As a matter of fact the recommendation regarding the use of PGP in the RIPE DB, as described in the RFC and the minutes of the DBSEC TF, was to use a PGP key for this purpose that was not used elsewhere.
When you receive a PGP-signed message, you need the public key of the signer to verify the signature. The program that updates the Database needs this information, and it is stored in the key-cert objects(*). With S/MIME, the certificate is sent with the message, and this certificate is signed by the CA. Since the database is configured to know how to verify certificates issued by specific CAs, we can verify the signature. No key-cert is necessary. But if we decide to allow any certficate, including self-signed, then we need some way to allow users to store this information in the database, for example key-cert objects. Unfortunately, this may cause problems, because (for instance) someone could create a key-cert object for a CA run by another organisation with bogus data, preventing users from using certificates *actually* issued by that CA. We could possibly require these sort of key-cert objects be reviewed by some method, for example RIPE DBM. However, if the RIPE NCC has no relationship with the CA, we have no real way to know the validity of any one request.
- will the RIPE NCC make avaiable, at the time of implementation, documentation to guide use of this feature by users with a couple of the most popular clients?
We are planning on including documenting use for popular clients as part of our research into S/MIME compatibility. This is expected before we add X.509 support for the RIPE NCC hostmasters. I would rather not delay implementing the X.509 authentication to the Database for this. -- Shane Kerr RIPE NCC (*) We used to also maintain a GnuPG key ring with this information, but now we build a temporary key ring each time we verify a signature, to avoid data synchronisation issues.
On Friday, August 15, 2003, at 04:23 PM, Shane Kerr wrote:
Joao,
Joao Luis Silva Damas wrote:
adding a new strong authentication method to the Database, is in my own personal opinion, a good thing(tm), particularly if the same credential can be used for other interactions with the RIPE NCC, make user's life easier. I wonder however about a few questions: - will this auth method be available only to RIPE NCC members? Is it not seen as a valuable general addition for non-member users of the IRR part of the RIPE DB?
Initially it will only be available for RIPE NCC members. There are three ways we could extend the service to non-LIRs:
1. Accept certificates from certain "well-known" CAs, for example Thawte, Verisign, etc.
2. Issue certificates from a RIPE NCC CA established for this purpose, and accept them.
3. Accept all certificates, including self-signed certificates.
#1 is relatively easy - the main overhead would be maintaining the Certificate Revokation Lists from the CAs. Deciding which CAs to support may also be tricky. #2 is also relatively easy, since we already have the technology. #3 is more difficult, and would require a slight change of the design, and administration issues (see below).
For DB authentication purposes, why do you need to verify the certificate? As with the PGP model[1], the only assumption one needs to make is that the message issuer is the holder of the private part of the certificate. If the RIPE DB is going to start making assertions about the real identity of the message sender, rather than just authorise or refuse updates, this seems to be a change in the model that warrants discussion in the working group. Is this so, or am I misinterpreting your description of the mechanism?
- Why the choice of not publishing the pulic part of the certificated in the DB? The choice to have a key-cert for the PGP method was not to do with issues of web of trust but rather for purposes of helping the users with their data maintenance. As a matter of fact the recommendation regarding the use of PGP in the RIPE DB, as described in the RFC and the minutes of the DBSEC TF, was to use a PGP key for this purpose that was not used elsewhere.
When you receive a PGP-signed message, you need the public key of the signer to verify the signature. The program that updates the Database needs this information, and it is stored in the key-cert objects(*).
With S/MIME, the certificate is sent with the message, and this certificate is signed by the CA. Since the database is configured to know how to verify certificates issued by specific CAs, we can verify the signature. No key-cert is necessary.
But if we decide to allow any certficate, including self-signed, then we need some way to allow users to store this information in the database, for example key-cert objects. Unfortunately, this may cause problems, because (for instance) someone could create a key-cert object for a CA run by another organisation with bogus data, preventing users from using certificates *actually* issued by that CA.
We could possibly require these sort of key-cert objects be reviewed by some method, for example RIPE DBM. However, if the RIPE NCC has no relationship with the CA, we have no real way to know the validity of any one request.
Why do you need to verify the certificate. Also, part of the idea of having a key-cert object was to allow users to check, not the DB, and to maintain DB self-consistency. Are these no longer desired features? Joao [1] RFC 2726
participants (3)
-
Joao Damas -
Joao Luis Silva Damas -
Shane Kerr