Re: do component managers need to authenticate researchers?

Leigh is basically right -- it is a nice simple architecture with a
central point of failure -- as long as your clearinghouse is a
high-availability system you would be fine.

But the idea of lightening the implementation burden on the AM doesn't
force everything to go through the clearinghouse.  The generalization is
to introduce an AM Security Connection Point (AM-SCP).  This is just the
part of the clearinghouse that accepts the SSL connection (or verifies
user certs in xmlsig format) and then forwards commands over the
pre-established secure channel to the AM.  That secure channel probably
just needs HMACs for integrity, so is considerably easier to support.

You can start by co-locating the AM-SCP with the Clearinghouse, but
provide a set of alternate servers and a place to lookup the complete
set of alternate addresses/ports/URIs.  This also gives you scalability,
and probably is not much more difficult to manage.

--Steve

-----Original Message-----
From: Leigh Stoller [mailto:stoller@...]
Sent: Monday, March 16, 2009 9:40 PM
To: Aaron Falk
Cc: Guido Appenzeller; gpo-tech@...; control-wg@...
Subject: Re: [cwg] do component managers need to authenticate
researchers?

> 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

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg