perfsonar development work

["Jeff W. Boote" <>]

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?

> 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.)

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:  
> <mailto:>
> Red.ES/RedIRIS Tel:+34 955 05 66 13
> Edificio CICA
> Avenida Reina Mercedes, s/n
> 41012 Sevilla
> SPAIN