« Return to Thread: do component managers need to authenticate researchers?
Re: do component managers need to authenticate researchers?
by Matt Mathis
::
Rate this Message:
I think ultimately we will need to do it both ways: the easy way in spiral 1
because it is expeditious, and "no single points of failure" isn't a
requirement. For most devices the best long term solution is for the AH to do
the authenticating.
However, a slightly different version of this problem comes up in Opt-In and
potentially other highly constrained substrates. It probably would not be a
good thing to require that all (future) AMs be capable of doing
authentication, because this will exclude some infrastructure.
Thanks,
--MM--
On Mon, 16 Mar 2009, Schwab, Stephen wrote:
> 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
>
_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg
because it is expeditious, and "no single points of failure" isn't a
requirement. For most devices the best long term solution is for the AH to do
the authenticating.
However, a slightly different version of this problem comes up in Opt-In and
potentially other highly constrained substrates. It probably would not be a
good thing to require that all (future) AMs be capable of doing
authentication, because this will exclude some infrastructure.
Thanks,
--MM--
On Mon, 16 Mar 2009, Schwab, Stephen wrote:
> 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
>
_______________________________________________
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 |
