do component managers need to authenticate researchers?

[Aaron Falk]

Several folks from Cluster B and the GPO met a few weeks ago to discuss
how to network switches would be integrated into this cluster.  Guido
Appenzeller, from the Enterprise GENI project. had some thoughts on
changes to the conceptual design's authentication approach that are
worth repeating here and possibly discussing further.  (Slides, minutes,
other reading can be found at [1].  In particular, see slides 41-50 of [2].)

To illustrate the issue, let's take the case of a researcher who wants
to contact an aggregate manager (AM) to make a resource reservation.
Notionally, a researcher would send this request and include signed
credentials that would give him authority to perform this task.  The
aggregate manager would verify the credentials were signed by an entity
the AM trusted.

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.

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.

>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.

Thanks,

--aaron

ps. Cluster B is going to add a prototype interface of this design.  In
fact, a PLC geniwrapper initial patch is already available at [3].

pps.  There was also an interesting discussion of the benefits of
SOAP/XSDL as compared to Pyton/XML-RPC and the patch above represents an
XSDL implementation of a control plane API.

[1] http://groups.geni.net/geni/wiki/ClusterB
[2]
http://groups.geni.net/geni/attachment/wiki/ClusterB/Enterprise%20Geni.pdf
[3] http://www.openflowswitch.org/wk/index.php/GENILight


--
Aaron Falk
Engineering Architect
GENI Project Office
http://www.geni.net, http://groups.geni.net

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

[Leigh Stoller]

> 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

[Schwab, Stephen]

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

[Matt Mathis]

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

[Camilo Viecco]

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

[Hongwei Zhang]

Another implication (and potential challenge) of the alternative approach is that the AM has to maintain the state of credentials. This appears to be a more stateful approach compared with the orignial one, and this may also have implications for the allowable time interval between a research getting his resource-access-credential and actually using the resource.

Of course, there may be constraints at switches that make the suggested alternative approach more attractive than the original one. It would be interesting to discuss such constriants and examine their implications for the GENI architecture.

Hongwei


Aaron Falk wrote:

Several folks from Cluster B and the GPO met a few weeks ago to discuss
how to network switches would be integrated into this cluster.  Guido
Appenzeller, from the Enterprise GENI project. had some thoughts on
changes to the conceptual design's authentication approach that are
worth repeating here and possibly discussing further.  (Slides, minutes,
other reading can be found at [1].  In particular, see slides 41-50 of [2].)

To illustrate the issue, let's take the case of a researcher who wants
to contact an aggregate manager (AM) to make a resource reservation. 
Notionally, a researcher would send this request and include signed
credentials that would give him authority to perform this task.  The
aggregate manager would verify the credentials were signed by an entity
the AM trusted. 

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. 

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.

>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.

Thanks,

--aaron

ps. Cluster B is going to add a prototype interface of this design.  In
fact, a PLC geniwrapper initial patch is already available at [3].

pps.  There was also an interesting discussion of the benefits of
SOAP/XSDL as compared to Pyton/XML-RPC and the patch above represents an
XSDL implementation of a control plane API.

[1] http://groups.geni.net/geni/wiki/ClusterB
[2]
http://groups.geni.net/geni/attachment/wiki/ClusterB/Enterprise%20Geni.pdf
[3] http://www.openflowswitch.org/wk/index.php/GENILight


  

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

[Leigh Stoller]

>



> I agree this makes CH more important. On the other hand we expect
> communication with at least our substrate to occur not very often
> and thus brief downtimes (e.g. for hours) would be tolerable. I
> think everyone agrees that prolonged downtimes (i.e. days) would be
> an issue for any architecture.

Yep, that is one mode of operation. We expect communication to be more
frequent in ProtoGeni. Also, it is not just downtime we are worried
about, but network partition; we would like the components to continue
to operate in the presence of partition.

> Outside of the federal government, there are few widely deployed
> systems that use PKI for anything but TLS authentication. Thus our
> proposal is to simplify GENI along similar lines.

What about ssh? Most people in the research community are quite
comfortable with ssh.

Lbs




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

[Jeff Chase]

I would like to ask a clarifying question.  It seems to be implicit in
this proposal and supporting material that the AM is viewed as the
switch element itself (or other substrate component).  If so, then
simplicity for the AM control protocol would be a dominating design
concern, since the protocol must be supported by the components/aggregates.

Is my interpretation correct?

An alternative is to place one or more stateful management servers in
the aggregate's domain, and give each one control over some set of
components/aggregates within that domain.  In Cluster D (Orca) we call
each aggregate's management server its controlling "authority" (e.g., a
site authority or domain authority).   The authority acts on behalf of
the aggregate's owner, and represents the aggregate externally, i.e., it
serves the AM role in the control plane protocol.  The interface between
the aggregate/component and its authority can be quite simple.   For
example, the component could maintain an SSL connection with its
authority, instead of with the CH as proposed here.  Or the interface
could be customized for different components/aggregates, since it is not
invoked from outside of the aggregate's domain.  It could use HMACs or
whatever instead of SSL.

I think the authority can play the role of the "AM Security Connection
Point (AM-SCP)", the alternative suggested by Steve Schwab.   Leigh
Stoller's concern about a central point of failure applies to the
authority as well, but you can partition the set of
components/aggregates across as many authority servers as you want, and
if an authority fails, then it only affects the components it directly
controls.  The authority offloads all the nasty
authentication/authorization stuff from the components and aggregates,
and in general, decouples components/aggregates from having to
understand the control plane protocols.  The authority may be complex,
but that is not so bad, because it is largely an off-the-shelf code with
some plugins specific to the components/aggregate types that it
controls.   The biggest downside is that the resource provider needs a
server to run it on.

This approach seems to me to be preferable to having the CH mediate all
communication between the researcher tools and components/aggregates, as
proposed here.  It meets the goal of the proposal as I understand it
(easy integration of new component types?) with only some of the
drawbacks.

Jeff



Aaron Falk wrote:

> Several folks from Cluster B and the GPO met a few weeks ago to discuss
> how to network switches would be integrated into this cluster.  Guido
> Appenzeller, from the Enterprise GENI project. had some thoughts on
> changes to the conceptual design's authentication approach that are
> worth repeating here and possibly discussing further.  (Slides, minutes,
> other reading can be found at [1].  In particular, see slides 41-50 of [2].)
>
> To illustrate the issue, let's take the case of a researcher who wants
> to contact an aggregate manager (AM) to make a resource reservation.
> Notionally, a researcher would send this request and include signed
> credentials that would give him authority to perform this task.  The
> aggregate manager would verify the credentials were signed by an entity
> the AM trusted.
>
> 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.
>
> 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.
>
> >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.
>
> Thanks,
>
> --aaron
>
> ps. Cluster B is going to add a prototype interface of this design.  In
> fact, a PLC geniwrapper initial patch is already available at [3].
>
> pps.  There was also an interesting discussion of the benefits of
> SOAP/XSDL as compared to Pyton/XML-RPC and the patch above represents an
> XSDL implementation of a control plane API.
>
> [1] http://groups.geni.net/geni/wiki/ClusterB
> [2]
> http://groups.geni.net/geni/attachment/wiki/ClusterB/Enterprise%20Geni.pdf
> [3] http://www.openflowswitch.org/wk/index.php/GENILight
>
>
>  

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

[Aaron Falk]

Hongwei Zhang wrote:
> Another implication (and potential challenge) of the alternative
> approach is that the AM has to maintain the state of credentials.

I don't think so.  In my (perhaps simple) understanding, the
**clearinghouse** maintains state of the credentials.  In fact, I think
that is the nut of the proposal.  A researcher presents credentials to
the CH, which validates them before forwarding the request to the AM.
The AM trusts the CH to perform the validation.

> This appears to be a more stateful approach compared with the orignial
> one, and this may also have implications for the allowable time
> interval between a research getting his resource-access-credential and
> actually using the resource.
Again, I don't think so.  As soon as the researcher gains access to the
clearinghouse (an 'account'), the CH can validate him.

--aaron

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

[Leigh Stoller]

>> Another implication (and potential challenge) of the alternative
>> approach is that the AM has to maintain the state of credentials.
>
> I don't think so.  In my (perhaps simple) understanding, the
> **clearinghouse** maintains state of the credentials.

So, in order to delegate a credential to my grad student, I have to
ask the CH to do it?

Our approach is to let the researcher delegate credentials themselves,
by signing it over, perhaps with priv changes. The beauty of PKI ...

>> This appears to be a more stateful approach compared with the  
>> orignial
>> one, and this may also have implications for the allowable time
>> interval between a research getting his resource-access-credential  
>> and
>> actually using the resource.
>
> Again, I don't think so.  As soon as the researcher gains access to
> the clearinghouse (an 'account'), the CH can validate him.

Seems like the CH is now in the critical path to doing anything! :-)

Lbs


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

[Hongwei Zhang]

Agreed, if EVERY communication between researchers and aggregates have to go through the clearinghouse. If I understand it right, this choice may have significant implications on the expected large scale, global GENI infrastructure.

I think Jeff's suggestions should be a good candidate solution to the issue we are trying to address here, in the sense not requiring a centralized solution while not requiring high-speed switches to deal with all the potentially complex interactions.

Hongwei


Aaron Falk wrote:

Hongwei Zhang wrote:
  

Another implication (and potential challenge) of the alternative
approach is that the AM has to maintain the state of credentials. 
    

I don't think so.  In my (perhaps simple) understanding, the
**clearinghouse** maintains state of the credentials.  In fact, I think
that is the nut of the proposal.  A researcher presents credentials to
the CH, which validates them before forwarding the request to the AM. 
The AM trusts the CH to perform the validation.

  

This appears to be a more stateful approach compared with the orignial
one, and this may also have implications for the allowable time
interval between a research getting his resource-access-credential and
actually using the resource.
    

Again, I don't think so.  As soon as the researcher gains access to the
clearinghouse (an 'account'), the CH can validate him.

--aaron
  

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

[Robert P Ricci]

Thus spake Jeff Chase on Thu, Mar 19, 2009 at 11:36:32AM -0400:
> I would like to ask a clarifying question.  It seems to be implicit in
> this proposal and supporting material that the AM is viewed as the
> switch element itself (or other substrate component).  If so, then
> simplicity for the AM control protocol would be a dominating design
> concern, since the protocol must be supported by the components/aggregates.
>
> Is my interpretation correct?

I believe it's not the location of the AM that's at issue here: the
existing architecture documents are pretty clear (I think) on the fact
that a CM/AM need not be physically located on the component - it might
be a service run somewhere else, which uses some "private" interface to
actually create the slivers. The AM for a 'traditional' switch
infrastructure, for example, might be a service that exports the CM API
to clients, and uses SNMP on the back end to create "slices" of the
network. So, no change is necessary to the current design in order to
allow OpenFlow to run an AM on a PC "near" the OpenFlow network at
Stanford.

The issue here, as I understand it, is whether every AM in the system
needs to be able to authenticate users and validate credentials, and
specifically whether AMs should have to participate in some sort of PKI.

The proposal raised by the OpenFlow project is one way to keep AMs from
having to participate in a PKI. By centralizing all operations, the
process of managing keys is simplified. There are other possible ways to
do this - eg. I find Steve Schwab's suggestion and interesting one.
 
In my view, though, it is not asking too much of the AMs to ask them to
authenticate users and validate credentials. In the ProtoGENI design, we
are basically using the "browser model", in which there is a well-known
set of trust roots, roughly corresponding to federates in the system -
federating with another facility essentially boils down to adding that
facility's CA to your set of trust roots. Authenticating users and
checking credentials is simply a matter of tracing standard certificates
and signatures back to one of these trust roots. Managing trust roots is
not a hard thing - at the simplest, some entity overseeing the
federation can simply supply a list of trust roots to all members of the
federation.

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

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

[Jeff Chase]

Rob,

I think we at least are in agreement then, except (perhaps) on the next
level of details about exactly what credentials should look like and
exactly what validation should happen where.

But I'm still wondering what motivates the CH-AM SSL proposal then,
since there are other ways to delegate user authentication to the CH if
that was the goal.   I suppose that was Steve Schwab's point.

As an aside, our (Orca and SHARP predecessor) approach is for the CH to
authenticate the user and apply whatever authorization/arbitration
policy it uses, and then issue signed tickets.  The AM has to validate
the tickets, and check that the tickets are not stolen, but it should
not have to deal with any other kind of user credential.  This approach
is similar to a PKI if one squints too much: in particular, a ticket is
a signed endorsement sort of like a certificate.  But it is different in
that it does not require (but does not preclude) a global identity or a
common set of trust anchors across the entire system.  Also, a ticket
only endorses the bearer for a particular purpose: use of some resource
set for a limited time.   It does not (necessarily) represent or certify
the identity of the bearer.

Jeff

Robert P Ricci wrote:

> Thus spake Jeff Chase on Thu, Mar 19, 2009 at 11:36:32AM -0400:
>  
>> I would like to ask a clarifying question.  It seems to be implicit in
>> this proposal and supporting material that the AM is viewed as the
>> switch element itself (or other substrate component).  If so, then
>> simplicity for the AM control protocol would be a dominating design
>> concern, since the protocol must be supported by the components/aggregates.
>>
>> Is my interpretation correct?
>>    
>
> I believe it's not the location of the AM that's at issue here: the
> existing architecture documents are pretty clear (I think) on the fact
> that a CM/AM need not be physically located on the component - it might
> be a service run somewhere else, which uses some "private" interface to
> actually create the slivers. The AM for a 'traditional' switch
> infrastructure, for example, might be a service that exports the CM API
> to clients, and uses SNMP on the back end to create "slices" of the
> network. So, no change is necessary to the current design in order to
> allow OpenFlow to run an AM on a PC "near" the OpenFlow network at
> Stanford.
>
> The issue here, as I understand it, is whether every AM in the system
> needs to be able to authenticate users and validate credentials, and
> specifically whether AMs should have to participate in some sort of PKI.
>
> The proposal raised by the OpenFlow project is one way to keep AMs from
> having to participate in a PKI. By centralizing all operations, the
> process of managing keys is simplified. There are other possible ways to
> do this - eg. I find Steve Schwab's suggestion and interesting one.
>  
> In my view, though, it is not asking too much of the AMs to ask them to
> authenticate users and validate credentials. In the ProtoGENI design, we
> are basically using the "browser model", in which there is a well-known
> set of trust roots, roughly corresponding to federates in the system -
> federating with another facility essentially boils down to adding that
> facility's CA to your set of trust roots. Authenticating users and
> checking credentials is simply a matter of tracing standard certificates
> and signatures back to one of these trust roots. Managing trust roots is
> not a hard thing - at the simplest, some entity overseeing the
> federation can simply supply a list of trust roots to all members of the
> federation.
>
>  

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

[Leigh Stoller]

> As an aside, our (Orca and SHARP predecessor) approach is for the CH  
> to
> authenticate the user and apply whatever authorization/arbitration
> policy it uses, and then issue signed tickets.  The AM has to validate
> the tickets, and check that the tickets are not stolen, but it should
> not have to deal with any other kind of user credential.  This  
> approach
> is similar to a PKI if one squints too much: in particular, a ticket  
> is
> a signed endorsement sort of like a certificate.  But it is  
> different in
> that it does not require (but does not preclude) a global identity  
> or a
> common set of trust anchors across the entire system.  Also, a ticket
> only endorses the bearer for a particular purpose: use of some  
> resource
> set for a limited time.   It does not (necessarily) represent or  
> certify
> the identity of the bearer.

But, you must certify the identity of the bearer somehow, correct?
Otherwise there is now way to determine if the credential was stolen.
There are a number of ways to do that, SSL being just one example.

That aside, in ProtoGeni it is the CMs that issue the tickets, since in
a widely distributed system, it seems difficult for the CH to know
precisely what resources are available at each CM. Sure, it is
possible, but then you are back to a very centralized system with all
the attendant problems. There are also policy issues that the CM may
want to enforce, that the CH is not aware of.

Lbs


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

[Jeff Chase]

Leigh Stoller wrote:

>> As an aside, our (Orca and SHARP predecessor) approach is for the CH to
>> authenticate the user and apply whatever authorization/arbitration
>> policy it uses, and then issue signed tickets.  The AM has to validate
>> the tickets, and check that the tickets are not stolen, but it should
>> not have to deal with any other kind of user credential.  This approach
>> is similar to a PKI if one squints too much: in particular, a ticket is
>> a signed endorsement sort of like a certificate.  But it is different in
>> that it does not require (but does not preclude) a global identity or a
>> common set of trust anchors across the entire system.  Also, a ticket
>> only endorses the bearer for a particular purpose: use of some resource
>> set for a limited time.   It does not (necessarily) represent or certify
>> the identity of the bearer.
>
> But, you must certify the identity of the bearer somehow, correct?
> Otherwise there is now way to determine if the credential was stolen.
> There are a number of ways to do that, SSL being just one example.

Yes, the AM verifies that the bearer possesses a private key that
matches a public key in the ticket, yes.
>
> That aside, in ProtoGeni it is the CMs that issue the tickets, since in
> a widely distributed system, it seems difficult for the CH to know
> precisely what resources are available at each CM. Sure, it is
> possible, but then you are back to a very centralized system with all
> the attendant problems. There are also policy issues that the CM may
> want to enforce, that the CH is not aware of.
Yes, there are all sorts of tradeoffs, yes, and different ways to
balance them within the control framework.     There's a lot to say
about all that, and I hope we can talk about it at GEC.

Jeff


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

[Jeff Chase]

After reviewing the round of 15 or so e-mail messages resulting from
this message, I'm still not sure there was a consensus before the
discussion petered out.

The exchange brought us down to a question of which of the following is
"simpler":

(1) Maintain an SSL connection with a trust anchor whose public key is
known, and process  commands arriving over that connection.

(2) Accept commands from anywhere, and verify that they are signed by a
trust anchor whose public key is known.

For my part, #2 seems more flexible and perhaps more robust.  But I'm
not sure I see any meaningful difference in terms of complexity.

I'm going to stick my neck out here and suggest that the real problem
that motivated this proposal (for option #1) was a rejection of option #3:

(3) Accept commands from anywhere, and verify that the issuer is
authorized to issue the command by checking the issuer's SFA credential.

I still don't understand SFA credentials, so I share the desire for a
simpler approach.  But I also hope that we don't react by requiring
option #1 and precluding option #2.

Jeff

Aaron Falk wrote:

> Several folks from Cluster B and the GPO met a few weeks ago to discuss
> how to network switches would be integrated into this cluster.  Guido
> Appenzeller, from the Enterprise GENI project. had some thoughts on
> changes to the conceptual design's authentication approach that are
> worth repeating here and possibly discussing further.  (Slides, minutes,
> other reading can be found at [1].  In particular, see slides 41-50 of [2].)
>
> To illustrate the issue, let's take the case of a researcher who wants
> to contact an aggregate manager (AM) to make a resource reservation.
> Notionally, a researcher would send this request and include signed
> credentials that would give him authority to perform this task.  The
> aggregate manager would verify the credentials were signed by an entity
> the AM trusted.
>
> 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.
>
> 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.
>
> >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.
>
> Thanks,
>
> --aaron
>
> ps. Cluster B is going to add a prototype interface of this design.  In
> fact, a PLC geniwrapper initial patch is already available at [3].
>
> pps.  There was also an interesting discussion of the benefits of
> SOAP/XSDL as compared to Pyton/XML-RPC and the patch above represents an
> XSDL implementation of a control plane API.
>
> [1] http://groups.geni.net/geni/wiki/ClusterB
> [2]
> http://groups.geni.net/geni/attachment/wiki/ClusterB/Enterprise%20Geni.pdf
> [3] http://www.openflowswitch.org/wk/index.php/GENILight
>
>
>  

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