« Return to Thread: do component managers need to authenticate researchers?
Re: do component managers need to authenticate researchers?
by Leigh Stoller
::
Rate this Message:
> The proposal on the table is for a simpler approach. The AM
> maintains an SSL connection to the clearinghouse (CH). Researcher
> credentials are sent to the AM by way of the clearinghouse and the
> validates the credentials before forwarding the request to the AM.
> This removes burden of validating the credentials from the AM at the
> expense of forcing requests to pass through the clearinghouse.
But this makes the CH a central point of failure and contention. This
seems like a bad idea, unless there is a pretty sophisticated
fail-over mechanism, which does not seem like a simplification.
> There is a fundamental change here in the need for a GENI-wide PKI
> is removed and the crypto functions in the AM are reduced to
> maintaining an SSL connection. Also, the aggregate manager's
> control plane API becomes much simpler, e.g., roles and credentials
> added many calls and options to the PlanetLab Slice-Federated
> Architecture. However, this changes the message flow in GENI in a
> significant way, making the clearinghouse a waypoint for control
> plane communications between researches and AMs.
This makes it sound like the researcher never actually contacts the AM
directly, since if the researcher did, the AM would be able to verify
the SSL certificate used to initiate the SSL connection? And if the AM
could do that, it could, with a little additional work, verify the
credential, right?
> From a near-term, implementation perspective, this seems like a
> advantageous change. A complex, not-well-understood function
> (researcher credential authentication) has been moved out of the
> development path of aggregates and their managers. However, I'd
> like to understand what the costs are of this design.
Our (ProtoGeni) approach to this was for the root certificates to be
cached at the AM/CMs so that it could verify the SSL certificates
directly. This simplification makes it possible to bypass part of
GENI's somewhat complicated delegation model, but still be able to
verify user certificates and credentials (in xmlsig format). However,
this simplification also assumes that the user certificates are
generated from a relatively small set of authorities, which seems
reasonable for a prototype implementation. At the same time, we still
manage to follow the architecture (roughly), with the hope that we
will solve the total PKI problem, later ...
I agree that a simplification is needed, to the benefit of all of us,
but I am not crazy about this approach.
My two cents.
Lbs
_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg
> maintains an SSL connection to the clearinghouse (CH). Researcher
> credentials are sent to the AM by way of the clearinghouse and the
> validates the credentials before forwarding the request to the AM.
> This removes burden of validating the credentials from the AM at the
> expense of forcing requests to pass through the clearinghouse.
But this makes the CH a central point of failure and contention. This
seems like a bad idea, unless there is a pretty sophisticated
fail-over mechanism, which does not seem like a simplification.
> There is a fundamental change here in the need for a GENI-wide PKI
> is removed and the crypto functions in the AM are reduced to
> maintaining an SSL connection. Also, the aggregate manager's
> control plane API becomes much simpler, e.g., roles and credentials
> added many calls and options to the PlanetLab Slice-Federated
> Architecture. However, this changes the message flow in GENI in a
> significant way, making the clearinghouse a waypoint for control
> plane communications between researches and AMs.
This makes it sound like the researcher never actually contacts the AM
directly, since if the researcher did, the AM would be able to verify
the SSL certificate used to initiate the SSL connection? And if the AM
could do that, it could, with a little additional work, verify the
credential, right?
> From a near-term, implementation perspective, this seems like a
> advantageous change. A complex, not-well-understood function
> (researcher credential authentication) has been moved out of the
> development path of aggregates and their managers. However, I'd
> like to understand what the costs are of this design.
Our (ProtoGeni) approach to this was for the root certificates to be
cached at the AM/CMs so that it could verify the SSL certificates
directly. This simplification makes it possible to bypass part of
GENI's somewhat complicated delegation model, but still be able to
verify user certificates and credentials (in xmlsig format). However,
this simplification also assumes that the user certificates are
generated from a relatively small set of authorities, which seems
reasonable for a prototype implementation. At the same time, we still
manage to follow the architecture (roughly), with the hope that we
will solve the total PKI problem, later ...
I agree that a simplification is needed, to the benefit of all of us,
but I am not crazy about this approach.
My two cents.
Lbs
_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg
« Return to Thread: do component managers need to authenticate researchers?
| Free embeddable forum powered by Nabble | Forum Help |
