OGF NSI networking architecture and need for certificates with restricted user base
Dear folks in the OGF CAOPS, VOMS-PROC and NSI working groups. I'd like to initiate some discussion among the participants in these working groups for the use case referred to in the talk at the link below. Some review of the conditions for this use case would be helpful. Note this is also a use case that comes up in Internet-of-Things discussions, and has caused some discussion on the PKIX group list (though that group is now dormant of course) and other related lists lately. To me this is a familiar situation with well-known parameters, but possibly some additional considerations, and might possibly lead to some useful communication among the members in these groups about solutions that could be applied using existing technologies that would avoid the possible downsides associated with the proposed use of self-signed certificates. (For example, extended attribute certificates as used in VOMS, though the same or perhaps through a different implementation, might be a good solution here; other solutions might be contemplated that would be more attractive than self-signed certificates for this situation.) Your comments, discussion and input are recruited (by me -- I'm not speaking for the NIS-WG members per se!), and I hope that all parties will regard this as useful discussion for information exchange only. Thanks, Alan Begin forwarded message: From: Guy Roberts <Guy.Roberts@dante.net<mailto:Guy.Roberts@dante.net>> Subject: RE: [Nsi-wg] Wednesday's NSI conf call Date: July 30, 2014 at 1:30:19 PM GMT+2 To: Alan Sill <kilohoku150@gmail.com<mailto:kilohoku150@gmail.com>> Hi Alan, Please find the slides on NSI security here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6592 The proposal is that NSAs will run their own private Certificate Authorities (self-signing) rather than using public Certificate Authorities. Participating NSAs will then exchange information about each other’s Certificates in an ad hoc way. This solution does not scale well as private Certificates have to be manually shared, but it reduces the size of the certificate pool. Guy From: Alan Sill [mailto:kilohoku150@gmail.com] Sent: 30 July 2014 10:56 To: Guy Roberts Cc: Alan Sill Subject: Re: [Nsi-wg] Wednesday's NSI conf call Guy, On Jul 30, 2014, at 11:02 AM, Guy Roberts <Guy.Roberts@dante.net<mailto:Guy.Roberts@dante.net>> wrote: - comments/feedback from last week’s presentation from John on ‘Secure Communications with Self Signed Certificates’ Are copies of these slides available? I would like to understand the context. (In general, use of self-signed certificates is risky at best, so I would like to understand the use case here.) Alan
Hi Alan, I think he's mixing authentication and authorization. If I look at page 10, my reaction is, there is nothing wrong in trusting that client cert #2 is client cert #2, that's only the authentication part. That doesn't mean you also *allow* client cert #2. Same on page 11, trusting a certificate there should mean trusting that the identity is what it claims to be. Doesn't mean allowing it to enter. If this is indeed his whole use-case, I would say, go for (a subset of) public CAs and restrict access based on specific DNs. That gives you still all the revocation and renewal possibilities while at the same time allowing for restricted access. A private CA could work, but is a lot of work, and not trivial to keep safe... Self-signed certificates will not scale. They give no way of revocation, big problems with expiry etc. If they need more advanced authZ, such as based on certain roles, than indeed VOMS attribute certificates might be useful, although that would mean software adaptations. Best wishes, Mischa Sallé On Wed, Jul 30, 2014 at 03:34:08PM +0000, Sill, Alan wrote:
Dear folks in the OGF CAOPS, VOMS-PROC and NSI working groups.
I'd like to initiate some discussion among the participants in these working groups for the use case referred to in the talk at the link below.
Some review of the conditions for this use case would be helpful. Note this is also a use case that comes up in Internet-of-Things discussions, and has caused some discussion on the PKIX group list (though that group is now dormant of course) and other related lists lately.
To me this is a familiar situation with well-known parameters, but possibly some additional considerations, and might possibly lead to some useful communication among the members in these groups about solutions that could be applied using existing technologies that would avoid the possible downsides associated with the proposed use of self-signed certificates. (For example, extended attribute certificates as used in VOMS, though the same or perhaps through a different implementation, might be a good solution here; other solutions might be contemplated that would be more attractive than self-signed certificates for this situation.)
Your comments, discussion and input are recruited (by me -- I'm not speaking for the NIS-WG members per se!), and I hope that all parties will regard this as useful discussion for information exchange only.
Thanks, Alan
Begin forwarded message:
From: Guy Roberts <Guy.Roberts@dante.net<mailto:Guy.Roberts@dante.net>> Subject: RE: [Nsi-wg] Wednesday's NSI conf call Date: July 30, 2014 at 1:30:19 PM GMT+2 To: Alan Sill <kilohoku150@gmail.com<mailto:kilohoku150@gmail.com>>
Hi Alan,
Please find the slides on NSI security here:
https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6592
The proposal is that NSAs will run their own private Certificate Authorities (self-signing) rather than using public Certificate Authorities. Participating NSAs will then exchange information about each other’s Certificates in an ad hoc way.
This solution does not scale well as private Certificates have to be manually shared, but it reduces the size of the certificate pool.
Guy
From: Alan Sill [mailto:kilohoku150@gmail.com] Sent: 30 July 2014 10:56 To: Guy Roberts Cc: Alan Sill Subject: Re: [Nsi-wg] Wednesday's NSI conf call
Guy,
On Jul 30, 2014, at 11:02 AM, Guy Roberts <Guy.Roberts@dante.net<mailto:Guy.Roberts@dante.net>> wrote:
- comments/feedback from last week’s presentation from John on ‘Secure Communications with Self Signed Certificates’
Are copies of these slides available? I would like to understand the context.
(In general, use of self-signed certificates is risky at best, so I would like to understand the use case here.)
Alan
_______________________________________________ voms-proc-wg mailing list voms-proc-wg@ogf.org https://www.ogf.org/mailman/listinfo/voms-proc-wg
-- Nikhef Room H155 Science Park 105 Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msalle@nikhef.nl __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
Yes, I was indeed mixing authentication and basic authorization. I have solved the issue by adding certification DN authorization in Apache after the TLS session is established. It is just too bad TLS gets established in the first place with these wide ranging CAs. Seems a bit senseless in the grand scheme of security. Java based implementations can override the default SSL Engine to give customized handling of the certificates, which solves my problem during the negotiation phase. Unfortunately, not everyone can do this. "Self-signed certificates will not scale." - It really depends on the deployment requirements of the application. We are discussing control plane peering of service agents, of which an organization will typically have a handful to tens for the foreseeable future. I would not use self-signed for use cases where I am dealing with 100 - 1,000s of clients. In that case it definitely does not scale. However, having to provision 1,000s of access control lists to restrict access does not scale as well. If this was the case an entirely different solution would be required that does not depend on SSL/TLS for anything other than encryption. As they say, six of one, half a dozen of the other. Thank you for the feedback. John On 2014-07-31, at 10:58 AM, Mischa Salle <msalle@nikhef.nl> wrote:
Hi Alan,
I think he's mixing authentication and authorization. If I look at page 10, my reaction is, there is nothing wrong in trusting that client cert #2 is client cert #2, that's only the authentication part. That doesn't mean you also *allow* client cert #2. Same on page 11, trusting a certificate there should mean trusting that the identity is what it claims to be. Doesn't mean allowing it to enter. If this is indeed his whole use-case, I would say, go for (a subset of) public CAs and restrict access based on specific DNs. That gives you still all the revocation and renewal possibilities while at the same time allowing for restricted access. A private CA could work, but is a lot of work, and not trivial to keep safe... Self-signed certificates will not scale. They give no way of revocation, big problems with expiry etc. If they need more advanced authZ, such as based on certain roles, than indeed VOMS attribute certificates might be useful, although that would mean software adaptations.
Best wishes, Mischa Sallé
On Wed, Jul 30, 2014 at 03:34:08PM +0000, Sill, Alan wrote:
Dear folks in the OGF CAOPS, VOMS-PROC and NSI working groups.
I'd like to initiate some discussion among the participants in these working groups for the use case referred to in the talk at the link below.
Some review of the conditions for this use case would be helpful. Note this is also a use case that comes up in Internet-of-Things discussions, and has caused some discussion on the PKIX group list (though that group is now dormant of course) and other related lists lately.
To me this is a familiar situation with well-known parameters, but possibly some additional considerations, and might possibly lead to some useful communication among the members in these groups about solutions that could be applied using existing technologies that would avoid the possible downsides associated with the proposed use of self-signed certificates. (For example, extended attribute certificates as used in VOMS, though the same or perhaps through a different implementation, might be a good solution here; other solutions might be contemplated that would be more attractive than self-signed certificates for this situation.)
Your comments, discussion and input are recruited (by me -- I'm not speaking for the NIS-WG members per se!), and I hope that all parties will regard this as useful discussion for information exchange only.
Thanks, Alan
Begin forwarded message:
From: Guy Roberts <Guy.Roberts@dante.net<mailto:Guy.Roberts@dante.net>> Subject: RE: [Nsi-wg] Wednesday's NSI conf call Date: July 30, 2014 at 1:30:19 PM GMT+2 To: Alan Sill <kilohoku150@gmail.com<mailto:kilohoku150@gmail.com>>
Hi Alan,
Please find the slides on NSI security here:
https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6592
The proposal is that NSAs will run their own private Certificate Authorities (self-signing) rather than using public Certificate Authorities. Participating NSAs will then exchange information about each other’s Certificates in an ad hoc way.
This solution does not scale well as private Certificates have to be manually shared, but it reduces the size of the certificate pool.
Guy
From: Alan Sill [mailto:kilohoku150@gmail.com] Sent: 30 July 2014 10:56 To: Guy Roberts Cc: Alan Sill Subject: Re: [Nsi-wg] Wednesday's NSI conf call
Guy,
On Jul 30, 2014, at 11:02 AM, Guy Roberts <Guy.Roberts@dante.net<mailto:Guy.Roberts@dante.net>> wrote:
- comments/feedback from last week’s presentation from John on ‘Secure Communications with Self Signed Certificates’
Are copies of these slides available? I would like to understand the context.
(In general, use of self-signed certificates is risky at best, so I would like to understand the use case here.)
Alan
_______________________________________________ voms-proc-wg mailing list voms-proc-wg@ogf.org https://www.ogf.org/mailman/listinfo/voms-proc-wg
-- Nikhef Room H155 Science Park 105 Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msalle@nikhef.nl __ .. ... _._. .... ._ ... ._ ._.. ._.. .._.. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi John, I'd like to point out that the International Grid Trust Federation - http://igtf.net - was established specifically to provide a high-quality source of trusted CAs used in global research cyberinfrastructure and has been fulfilling this role for many years. These certificates, both for individuals and for hosts or services, provide the trust federation basis for large-scale computational grids and associated cloud projects, and might be a good source for your project. Generally obtaining grid certificates is available through national research and education initiatives or associated projects. OGF is on the verge of announcing free availability of these certificates to its members to make them available more broadly, and in addition will be supporting the availability of commercially trusted certificates (useful for those cases where you do want the certificate pre-loaded without going through installing an IGTF trust store to support your application) at discounted rates from the same supplier as the free grid ones. We do have a pretty well developed authorization community that can help with implementation issues like the ones that you mentioned. As for the widespread availability of certificates, this is generally seen as a good thing, depending on your needs. Obtaining a certificate from a commercial CA is easy, of course, and doesn't require the individual identity verification that is required by at least some of the IGTF profiles. For control-plane peering of service agents, I assume that simple possession of a valid certificate is not enough, and what you need is an authorization layer that says that a particular DN is allowed to carry out operations on the network function being controlled. We had planned to put together a workshop on identity management for software defined networking for SC'14, but I don't think we got that submitted in time. This sounds like a topic that would be good to discuss at an OGF meeting or other gathering of the NSI group. Alan On Jul 31, 2014, at 6:21 PM, John MacAuley <macauley@es.net> wrote:
Yes, I was indeed mixing authentication and basic authorization. I have solved the issue by adding certification DN authorization in Apache after the TLS session is established. It is just too bad TLS gets established in the first place with these wide ranging CAs. Seems a bit senseless in the grand scheme of security.
Java based implementations can override the default SSL Engine to give customized handling of the certificates, which solves my problem during the negotiation phase. Unfortunately, not everyone can do this.
"Self-signed certificates will not scale." - It really depends on the deployment requirements of the application. We are discussing control plane peering of service agents, of which an organization will typically have a handful to tens for the foreseeable future. I would not use self-signed for use cases where I am dealing with 100 - 1,000s of clients. In that case it definitely does not scale. However, having to provision 1,000s of access control lists to restrict access does not scale as well. If this was the case an entirely different solution would be required that does not depend on SSL/TLS for anything other than encryption.
As they say, six of one, half a dozen of the other.
Thank you for the feedback.
John
On 2014-07-31, at 10:58 AM, Mischa Salle <msalle@nikhef.nl> wrote:
Hi Alan,
I think he's mixing authentication and authorization. If I look at page 10, my reaction is, there is nothing wrong in trusting that client cert #2 is client cert #2, that's only the authentication part. That doesn't mean you also *allow* client cert #2. Same on page 11, trusting a certificate there should mean trusting that the identity is what it claims to be. Doesn't mean allowing it to enter. If this is indeed his whole use-case, I would say, go for (a subset of) public CAs and restrict access based on specific DNs. That gives you still all the revocation and renewal possibilities while at the same time allowing for restricted access. A private CA could work, but is a lot of work, and not trivial to keep safe... Self-signed certificates will not scale. They give no way of revocation, big problems with expiry etc. If they need more advanced authZ, such as based on certain roles, than indeed VOMS attribute certificates might be useful, although that would mean software adaptations.
Best wishes, Mischa Sallé
On Wed, Jul 30, 2014 at 03:34:08PM +0000, Sill, Alan wrote:
Dear folks in the OGF CAOPS, VOMS-PROC and NSI working groups.
I'd like to initiate some discussion among the participants in these working groups for the use case referred to in the talk at the link below.
Some review of the conditions for this use case would be helpful. Note this is also a use case that comes up in Internet-of-Things discussions, and has caused some discussion on the PKIX group list (though that group is now dormant of course) and other related lists lately.
To me this is a familiar situation with well-known parameters, but possibly some additional considerations, and might possibly lead to some useful communication among the members in these groups about solutions that could be applied using existing technologies that would avoid the possible downsides associated with the proposed use of self-signed certificates. (For example, extended attribute certificates as used in VOMS, though the same or perhaps through a different implementation, might be a good solution here; other solutions might be contemplated that would be more attractive than self-signed certificates for this situation.)
Your comments, discussion and input are recruited (by me -- I'm not speaking for the NIS-WG members per se!), and I hope that all parties will regard this as useful discussion for information exchange only.
Thanks, Alan
Begin forwarded message:
From: Guy Roberts <Guy.Roberts@dante.net<mailto:Guy.Roberts@dante.net>> Subject: RE: [Nsi-wg] Wednesday's NSI conf call Date: July 30, 2014 at 1:30:19 PM GMT+2 To: Alan Sill <kilohoku150@gmail.com<mailto:kilohoku150@gmail.com>>
Hi Alan,
Please find the slides on NSI security here:
https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6592
The proposal is that NSAs will run their own private Certificate Authorities (self-signing) rather than using public Certificate Authorities. Participating NSAs will then exchange information about each other’s Certificates in an ad hoc way.
This solution does not scale well as private Certificates have to be manually shared, but it reduces the size of the certificate pool.
Guy
From: Alan Sill [mailto:kilohoku150@gmail.com] Sent: 30 July 2014 10:56 To: Guy Roberts Cc: Alan Sill Subject: Re: [Nsi-wg] Wednesday's NSI conf call
Guy,
On Jul 30, 2014, at 11:02 AM, Guy Roberts <Guy.Roberts@dante.net<mailto:Guy.Roberts@dante.net>> wrote:
- comments/feedback from last week’s presentation from John on ‘Secure Communications with Self Signed Certificates’
Are copies of these slides available? I would like to understand the context.
(In general, use of self-signed certificates is risky at best, so I would like to understand the use case here.)
Alan
_______________________________________________ voms-proc-wg mailing list voms-proc-wg@ogf.org https://www.ogf.org/mailman/listinfo/voms-proc-wg
-- Nikhef Room H155 Science Park 105 Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msalle@nikhef.nl __ .. ... _._. .... ._ ... ._ ._.. ._.. .._.. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi John, just a few additional remarks inline... On Thu, Jul 31, 2014 at 12:21:59PM -0400, John MacAuley wrote:
Yes, I was indeed mixing authentication and basic authorization. I have solved the issue by adding certification DN authorization in Apache after the TLS session is established. It is just too bad TLS gets established in the first place with these wide ranging CAs. Seems a bit senseless in the grand scheme of security. I'm not sure I fully understand what you mean, but note in any case that you can easily provide a CA file or path with a (small) set of accepted CAs for client auth in Apache, see http://httpd.apache.org/docs/current/mod/mod_ssl.html under SSLCACertificateFile, SSLCACertificatePath and SSLCADNRequestFile, SSLCADNRequestPath
Java based implementations can override the default SSL Engine to give customized handling of the certificates, which solves my problem during the negotiation phase. Unfortunately, not everyone can do this. First of all, the standard mod_ssl has a number of possibilities for customization and you already get quite some data back from the Apache server, such as issuer CA for the client-cert etc., so you can also do quite some checks after the SSL handshake, for example in PHP. Also see below, about e.g. mod_gridsite.
"Self-signed certificates will not scale." - It really depends on the deployment requirements of the application. We are discussing control plane peering of service agents, of which an organization will typically have a handful to tens for the foreseeable future. I would not use self-signed for use cases where I am dealing with 100 - 1,000s of clients. In that case it definitely does not scale. True, but even for smaller cases, it can be difficult to handle the revocation or expiry of a certificate, as it has to be quickly distributed over all services and clients.
However, having to provision 1,000s of access control lists to restrict access does not scale as well. If this was the case an entirely different solution would be required that does not depend on SSL/TLS for anything other than encryption. in principle in the Grid world, people have developed an Apache module (mod_gridsite.so, shipped as part of gridsite which is available in both RedHat via EPEL and Debian) which can handle access control based on virtual organization (VO) membership, roles etc. especially to address your point about the ACLs. The grid also started out using long lists of user DNs, until we moved to the concept of a VO with roles and groups and access control based on that.
On Thu, Jul 31, 2014 at 05:50:08PM +0000, Sill, Alan wrote:
We had planned to put together a workshop on identity management for software defined networking for SC'14, but I don't think we got that submitted in time. This sounds like a topic that would be good to discuss at an OGF meeting or other gathering of the NSI group. That would be very interesting.
Best wishes, Mischa -- Nikhef Room H155 Science Park 105 Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msalle@nikhef.nl __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
Hi First, a +1 on what Mischa Salle wrote. There are several misconceptions in the presentation: Presenting the java trust/key store as a TLS protocol concept, client certificates should probably be host certificates, though the difference is limited to some certificate attributes. The boxed text on slide 11 seems to be the main "problem" in the presentation. However it is a fundemental concept of PKI, and it is NOT a weakness or a problem. I know some TLS implementations tend to hide the DN or make it overly complicated to get it, which is pretty bad (generally wrappers for http clients). The whole thing seems like an eloborate attempt to overcome this problem. The suggestion to use self-signed certs essentially makes authN and authZ the same thing removing the need to do any in-app checking. This is extremely inflexible though and just moves the AuthZ to TLS certificate configuration (which is not where it is supposed to be), while adding manual certificate handling. Finally it also unenforceable and the options does not exclude each other. GEANT and NORDUnet uses TERENA certs (and I doubt that will change), where SURFnet uses self-signed certs. Yet the NSI agents of these networks trust each other and communicate just fine. Personally I only add the needed CAs to the NORDUnet NSI Agent CA list, as there have been a bit too many CA slips recently. The first point on slide 16 is complete bullshit (and manipulative). While PKI isn't perfect, switching to a fully manual self-signed setup is extremely error-prone as it is generally difficult to manage certificates. Finally: Why exactly do we need to standardize how NSI agents thrust each other besides what is mentioned in the NSI Security section? /Henrik On Wed, 30 Jul 2014, Sill, Alan wrote:
Dear folks in the OGF CAOPS, VOMS-PROC and NSI working groups. I'd like to initiate some discussion among the participants in these working groups for the use case referred to in the talk at the link below.
Some review of the conditions for this use case would be helpful. Note this is also a use case that comes up in Internet-of-Things discussions, and has caused some discussion on the PKIX group list (though that group is now dormant of course) and other related lists lately.
To me this is a familiar situation with well-known parameters, but possibly some additional considerations, and might possibly lead to some useful communication among the members in these groups about solutions that could be applied using existing technologies that would avoid the possible downsides associated with the proposed use of self-signed certificates. (For example, extended attribute certificates as used in VOMS, though the same or perhaps through a different implementation, might be a good solution here; other solutions might be contemplated that would be more attractive than self-signed certificates for this situation.)
Your comments, discussion and input are recruited (by me -- I'm not speaking for the NIS-WG members per se!), and I hope that all parties will regard this as useful discussion for information exchange only.
Thanks, Alan
Begin forwarded message:
From: Guy Roberts <Guy.Roberts@dante.net> Subject: RE: [Nsi-wg] Wednesday's NSI conf call Date: July 30, 2014 at 1:30:19 PM GMT+2 To: Alan Sill <kilohoku150@gmail.com>
Hi Alan, Please find the slides on NSI security here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6592 The proposal is that NSAs will run their own private Certificate Authorities (self-signing) rather than using public Certificate Authorities. Participating NSAs will then exchange information about each other’s Certificates in an ad hoc way. This solution does not scale well as private Certificates have to be manually shared, but it reduces the size of the certificate pool. Guy From: Alan Sill [mailto:kilohoku150@gmail.com] Sent: 30 July 2014 10:56 To: Guy Roberts Cc: Alan Sill Subject: Re: [Nsi-wg] Wednesday's NSI conf call Guy, On Jul 30, 2014, at 11:02 AM, Guy Roberts <Guy.Roberts@dante.net> wrote:
- comments/feedback from last week’s presentation from John on ‘Secure Communications with Self Signed Certificates’
Are copies of these slides available? I would like to understand the context. (In general, use of self-signed certificates is risky at best, so I would like to understand the use case here.) Alan
Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Glad to see Henrik is back from vacation and in a good mood. Thanks for the input. On 2014-08-06, at 9:12 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi
First, a +1 on what Mischa Salle wrote.
There are several misconceptions in the presentation: Presenting the java trust/key store as a TLS protocol concept, client certificates should probably be host certificates, though the difference is limited to some certificate attributes.
The boxed text on slide 11 seems to be the main "problem" in the presentation. However it is a fundemental concept of PKI, and it is NOT a weakness or a problem. I know some TLS implementations tend to hide the DN or make it overly complicated to get it, which is pretty bad (generally wrappers for http clients). The whole thing seems like an eloborate attempt to overcome this problem.
The suggestion to use self-signed certs essentially makes authN and authZ the same thing removing the need to do any in-app checking. This is extremely inflexible though and just moves the AuthZ to TLS certificate configuration (which is not where it is supposed to be), while adding manual certificate handling.
Finally it also unenforceable and the options does not exclude each other. GEANT and NORDUnet uses TERENA certs (and I doubt that will change), where SURFnet uses self-signed certs. Yet the NSI agents of these networks trust each other and communicate just fine. Personally I only add the needed CAs to the NORDUnet NSI Agent CA list, as there have been a bit too many CA slips recently.
The first point on slide 16 is complete bullshit (and manipulative). While PKI isn't perfect, switching to a fully manual self-signed setup is extremely error-prone as it is generally difficult to manage certificates.
Finally: Why exactly do we need to standardize how NSI agents thrust each other besides what is mentioned in the NSI Security section?
/Henrik
On Wed, 30 Jul 2014, Sill, Alan wrote:
Dear folks in the OGF CAOPS, VOMS-PROC and NSI working groups. I'd like to initiate some discussion among the participants in these working groups for the use case referred to in the talk at the link below. Some review of the conditions for this use case would be helpful. Note this is also a use case that comes up in Internet-of-Things discussions, and has caused some discussion on the PKIX group list (though that group is now dormant of course) and other related lists lately. To me this is a familiar situation with well-known parameters, but possibly some additional considerations, and might possibly lead to some useful communication among the members in these groups about solutions that could be applied using existing technologies that would avoid the possible downsides associated with the proposed use of self-signed certificates. (For example, extended attribute certificates as used in VOMS, though the same or perhaps through a different implementation, might be a good solution here; other solutions might be contemplated that would be more attractive than self-signed certificates for this situation.) Your comments, discussion and input are recruited (by me -- I'm not speaking for the NIS-WG members per se!), and I hope that all parties will regard this as useful discussion for information exchange only. Thanks, Alan Begin forwarded message:
From: Guy Roberts <Guy.Roberts@dante.net> Subject: RE: [Nsi-wg] Wednesday's NSI conf call Date: July 30, 2014 at 1:30:19 PM GMT+2 To: Alan Sill <kilohoku150@gmail.com> Hi Alan,
Please find the slides on NSI security here:
https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6592
The proposal is that NSAs will run their own private Certificate Authorities (self-signing) rather than using public Certificate Authorities. Participating NSAs will then exchange information about each other’s Certificates in an ad hoc way.
This solution does not scale well as private Certificates have to be manually shared, but it reduces the size of the certificate pool.
Guy
From: Alan Sill [mailto:kilohoku150@gmail.com] Sent: 30 July 2014 10:56 To: Guy Roberts Cc: Alan Sill Subject: Re: [Nsi-wg] Wednesday's NSI conf call
Guy,
On Jul 30, 2014, at 11:02 AM, Guy Roberts <Guy.Roberts@dante.net> wrote:
- comments/feedback from last week’s presentation from John on ‘Secure Communications with Self Signed Certificates’
Are copies of these slides available? I would like to understand the context.
(In general, use of self-signed certificates is risky at best, so I would like to understand the use case here.)
Alan
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi Henrik, all, On 06/08/14 15:12, Henrik Thostrup Jensen wrote:
First, a +1 on what Mischa Salle wrote.
There are several misconceptions in the presentation: Presenting the java trust/key store as a TLS protocol concept, client certificates should probably be host certificates, though the difference is limited to some certificate attributes.
The boxed text on slide 11 seems to be the main "problem" in the presentation. However it is a fundemental concept of PKI, and it is NOT a weakness or a problem. I know some TLS implementations tend to hide the DN or make it overly complicated to get it, which is pretty bad (generally wrappers for http clients). The whole thing seems like an eloborate attempt to overcome this problem.
The suggestion to use self-signed certs essentially makes authN and authZ the same thing removing the need to do any in-app checking. This is extremely inflexible though and just moves the AuthZ to TLS certificate configuration (which is not where it is supposed to be), while adding manual certificate handling.
Finally it also unenforceable and the options does not exclude each other. GEANT and NORDUnet uses TERENA certs (and I doubt that will change), where SURFnet uses self-signed certs.
Just to be correct, from the start SURFnet has been using TERENA certificates to secure NSI control plane session.
Yet the NSI agents of these networks trust each other and communicate just fine. Personally I only add the needed CAs to the NORDUnet NSI Agent CA list, as there have been a bit too many CA slips recently.
The first point on slide 16 is complete bullshit (and manipulative). While PKI isn't perfect, switching to a fully manual self-signed setup is extremely error-prone as it is generally difficult to manage certificates.
Finally: Why exactly do we need to standardize how NSI agents thrust each other besides what is mentioned in the NSI Security section?
That was always my intention, and that is why the text is phrase as it is right now. How particular deployments want to implement control plane security is up to them, I do not want to enforce the use of self-signed certs or the use of any particular CA or rules on what attributes need to be checked or not. What I do expect to happen, if for example NSI is deployed in a grid environments, is that NSAs will most likely start using existing CA infrastructure and existing attributes to check, just because it is already there and convenient to use. But in general, the whole idea is that you decide with your peer what means of authorization is sufficient to you both, and if it is acceptable to you this can mean that you will have different ways to authorize different peers. Cheers, HansT.
On Wed, 30 Jul 2014, Sill, Alan wrote:
Dear folks in the OGF CAOPS, VOMS-PROC and NSI working groups. I'd like to initiate some discussion among the participants in these working groups for the use case referred to in the talk at the link below.
Some review of the conditions for this use case would be helpful. Note this is also a use case that comes up in Internet-of-Things discussions, and has caused some discussion on the PKIX group list (though that group is now dormant of course) and other related lists lately.
To me this is a familiar situation with well-known parameters, but possibly some additional considerations, and might possibly lead to some useful communication among the members in these groups about solutions that could be applied using existing technologies that would avoid the possible downsides associated with the proposed use of self-signed certificates. (For example, extended attribute certificates as used in VOMS, though the same or perhaps through a different implementation, might be a good solution here; other solutions might be contemplated that would be more attractive than self-signed certificates for this situation.)
Your comments, discussion and input are recruited (by me -- I'm not speaking for the NIS-WG members per se!), and I hope that all parties will regard this as useful discussion for information exchange only.
Thanks, Alan
Begin forwarded message:
From: Guy Roberts <Guy.Roberts@dante.net> Subject: RE: [Nsi-wg] Wednesday's NSI conf call Date: July 30, 2014 at 1:30:19 PM GMT+2 To: Alan Sill <kilohoku150@gmail.com>
Hi Alan,
Please find the slides on NSI security here:
https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6592
The proposal is that NSAs will run their own private Certificate Authorities (self-signing) rather than using public Certificate Authorities. Participating NSAs will then exchange information about each other's Certificates in an ad hoc way.
This solution does not scale well as private Certificates have to be manually shared, but it reduces the size of the certificate pool.
Guy
From: Alan Sill [mailto:kilohoku150@gmail.com] Sent: 30 July 2014 10:56 To: Guy Roberts Cc: Alan Sill Subject: Re: [Nsi-wg] Wednesday's NSI conf call
Guy,
On Jul 30, 2014, at 11:02 AM, Guy Roberts <Guy.Roberts@dante.net> wrote:
- comments/feedback from last week's presentation from John on 'Secure Communications with Self Signed Certificates'
Are copies of these slides available? I would like to understand the context.
(In general, use of self-signed certificates is risky at best, so I would like to understand the use case here.)
Alan
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
participants (5)
-
Hans Trompert -
Henrik Thostrup Jensen -
John MacAuley -
Mischa Salle -
Sill, Alan