perfsonar development work

["Jeff W. Boote" <>]

Diego R. Lopez wrote:
> Hi,
>
> On 5 Mar 2007, at 16:44, Cándido Rodríguez Montes wrote:
> > I've CCed this email to Diego López, who can tell us what's his 
> > feeling about this topic.
>
> Apart from some minor aspects (I'd say that the cert/SAML would be used 
> for authentication in
> the phase we are discussing, not for authorization), I think this 
> proposal makes sense.
> It allows to manage all requests in a unique way, so the library and 
> components are going
> to be more coherent, and limits the amount of eduGAIN certs strictly to 
> those required for authentication, allowing any other for encrypting the 
> data channels and thus providng an
> additional degree of freedom for deploying the infrastructure.

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