« Return to Thread: do component managers need to authenticate researchers?
Re: do component managers need to authenticate researchers?
by Camilo Viecco
::
Rate this Message:
I Like the proposal, in particular getting away from PKI.
On other similar theme. I am worried about naming and identity in GENI.
Are GID's as defined really needed? As the Enteprise GENI group
discussed in their document, there are already well known identifiers on
the Internet:
Users/principals/agents: email addresses
Hosts/Nodes/Slivers: domain names
Everything else: URLs
These identifiers are not only human readable but would allow us to
reuse and adapt
tools and libraries already in use with no or minimal changes.
In the same discussion, I keep asking myself of the benefits
(if you know the anwers please enlighten me), as specified in the SFA, of:
1. Having the same name-space for all entities.
2. Having both a UUID and a unique name as part of an identifier.
3. Having a unique name that can map to different entities: node, slice,
principal.
4. Requiring a PKI but not defining what are the anchors of trust of the
PKI.
-Should cerificate verification stop at the first known CA?
-How many CA's would there be (how many public keys will be able
to sign everything)?
5. Requiring a PKI AND requiring certificates for identifiers. (GID's
are certificates)
6. Having a hierarchy inverse of the current usage on the Internet/URLS.
It is my opinion identity and authentication are being convoluted in the
current design document and
that solving should be a priority for GENI.
Using current Internet identifiers is more sensible,rapidly and
correctly deployable than designing a
new naming and unproved naming/identity scheme.
thanks.
Camilo Viecco
Matt Mathis wrote:
> 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
>
_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg
On other similar theme. I am worried about naming and identity in GENI.
Are GID's as defined really needed? As the Enteprise GENI group
discussed in their document, there are already well known identifiers on
the Internet:
Users/principals/agents: email addresses
Hosts/Nodes/Slivers: domain names
Everything else: URLs
These identifiers are not only human readable but would allow us to
reuse and adapt
tools and libraries already in use with no or minimal changes.
In the same discussion, I keep asking myself of the benefits
(if you know the anwers please enlighten me), as specified in the SFA, of:
1. Having the same name-space for all entities.
2. Having both a UUID and a unique name as part of an identifier.
3. Having a unique name that can map to different entities: node, slice,
principal.
4. Requiring a PKI but not defining what are the anchors of trust of the
PKI.
-Should cerificate verification stop at the first known CA?
-How many CA's would there be (how many public keys will be able
to sign everything)?
5. Requiring a PKI AND requiring certificates for identifiers. (GID's
are certificates)
6. Having a hierarchy inverse of the current usage on the Internet/URLS.
It is my opinion identity and authentication are being convoluted in the
current design document and
that solving should be a priority for GENI.
Using current Internet identifiers is more sensible,rapidly and
correctly deployable than designing a
new naming and unproved naming/identity scheme.
thanks.
Camilo Viecco
Matt Mathis wrote:
> 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
>
_______________________________________________
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 |
