El 09/03/2007, a las 18:35, Jeff W. Boote escribió:
Cándido Rodríguez Montes wrote:
Hi Jeff,
you're right when you said we have some degree of freedom in using other certificates for deployment. As I read in the AS specification document, we're going to use certificates issued by the eduGAIN CA or by one of the subordinate CAs but also it's open to include others CAs.
But all perfSONAR components SHOULD have all root certs. It makes sense when you have a few root certs, not when every organization has its own root cert. In our scenary, we have one for eduGAIN CA and one for subordinate CAs, and I suppose organizations from Internet2 have the same root cert. In the worst case, I guess we would have 5-10 root certs, wouldn't we?
I am not very hopeful that we could corral our community into using a common CA for the Root. (Diego has heard me say this before.) But, perhaps we can at least minimize the number of CA's. I'm fairly sure we will need to have at least 3 for the USA: DOE, DOD, Edu. (I'm not convinced we can actually convince all the Edu sites to use a common root - but we can try.)
And, how would you actually deploy the Root-Cert of new organizations (even if it was a large group of organizations all using the same Root) out to all current participants?
This is a typical problem in a federation. For example, in Shibboleth, you need to share the metadata of all Identity providers (IdP) and Service providers (SP), in which you can find their certs and their root certs. So, it's the same problem when a new IdP/SP wants to join to the federation, because all members have to update their metadata collection. I saw in Switch (the Switzerland research and educational network) they've published an script to update the metadata informacion all days.
Some ideas occur to me for a solution:
- The AS package includes a keystore with all root certs. If a new organization wants to join, we'll add its root cert into the keystore and we must update the AS.
- Once a day, the AS checks all Metadata Services and gets all root certs. [I like very much this option]
- We can code some operations for add/delete root certs. [I think this is the most difficult and dangerous option]
In this scenary, we have resolved all trust problems in SSL communication.
It was my understanding that only the AS perfSONAR component would need to have this information. Resources local to the AS would need to share a root so they could communicate securely - but it was my understanding that certificate validation would be handled by EduGAIN components. There are no EduGAIN components at the resource itself... I thought the resource would need to send the client certificate to the AS to have it validated before it could really trust it. (Or perhaps it could request the certificate chain - that way it can cache valid certs - but this means CRL functionality would need to be handled at every since resource as well. One of the goals of our architecture was to minimize the amount of state information that each resource would need to have. I would much prefer this federation state be held only at the AS.)
Mmm, in case we want to use the same certificate for TLS and for Authorization process I guess application servers (Tomcat, for example) need to have all root certs if they want to validate the certificate used by clients for connecting to resources.
But, at the moment we've decided don't use TLS for Authorization purposes, I think this is not our business. I mean, you're right when you said that the resource doesn't need to process the certificate (so it doesn't need any eduGAIN component). It sends the certficate thought the SOAP message to the AS, and this validates the cert using the eduGAIN validation library.
So, when a resource receives a message, it can trust its content because that message has been received by TLS. And then, if the resource wants to require an authorization for that message, it sends an authorization request to the AS including the certificate that the client has sent using WS-SEC for Authorization purposes.
Regards
jeff
Regards
El 06/03/2007, a las 16:24, Jeff W. Boote escribió:
Hi Diego, Candido,
I have a question about this.
In our model, the client first talks with the H-BE to get authenticated. Since both the client, and the H-BE are from the same domain, it is easy for me to see how they can speak SSL with no problems - they will each accept the root-cert of the same organization.
Where I get confused is in the case of federation for the SSL communication.
Can we examine the case where the client then attempts to speak with a resource from a different domain? It was my understanding that the client would be getting a certificate from the SASL-CA as part of authenticating. I assumed it would be using that certificate for the SSL communication with the resource. And, I assumed it would be necessary to do that - because this short-term certificate would somehow have its X.509 root based at something the resource could accept as a valid root. The resource might need to contact the AS to determine it is valid of course. (Perhaps this is my confusion - does the act of federating require all organizations in the federation to exchange root certificates? Or is this what is really stored in the federated metadata service?)
In any case, this interaction makes me wonder how the client could accept the certificate of the resource. I guess we just do the same thing that web browsers do when they can't validate a root? Prompt the user? Or do we need an interaction back to the H-BE (or a metadata service) to allow the client to validate the cert of the resource? The H-BE (or something - not the client) should somehow know the root certs of federated domains, right? Just like the AS of the resource (and therefore the R-BE) knows something about the root cert of the domain of the user.
Hopefully my question is clear... What brought this up for me is when you said we would have some degree of freedom in using other certificates for deployment. I'm not sure I see how that could work - unless you are saying we do not worry at all about the authentication provided by the SSL connection. But, in this case, I would be worried about man-in-the-middle attacks. If it is just a random certificate used for the communication, then you have no way of knowing if you are talking to an intermediary, right?
Thanks,
jeff
--
Cándido Rodríguez Montes E-mail: <>
Red.ES/RedIRIS Tel:+34 955 05 66 13
Edificio CICA
Avenida Reina Mercedes, s/n
41012 Sevilla
SPAIN
