Nabble - GENI Control Framework WG

Re: Initial investigation result of federation issues

2009-11-12T07:35:51Z

Sangjin, Rob --
Following this line of thought further -- perhaps the interesting thing
that Sangjin and his colleagues might be able to share are the policies
that they have already been using on their own testbed -- or the
policies they would *like* to apply, both within their own local
testbed, across various Korean testbeds that might be viewed as a
Korean-GENI, and at the larger-scale of GENI-FIRE-Korea-Japan...

To be very concrete, how can Sangjin's testbed connect to the current
protoGENI/Internet2 infrastructure? Is there anything special we might
have to do regarding allocation policy for the network path between an
Internet2 PoP and the wide-area research network Sangjin's testbed
connects to?

Thanks,

--Steve

-----Original Message-----
From: control-wg-bounces@... [mailto:control-wg-bounces@...]
On Behalf Of Robert P Ricci
Sent: Thursday, November 12, 2009 8:34 AM
To: Sangjin Jeong
Cc: control-wg@...
Subject: Re: [cwg] Initial investigation result of federation issues

On Slide 11, you mention different possible levels of federation.

There's a federation going within the US for sites based on the Emulab
software. So far, we have very simple policies for giving access to
members of that federation, but it seems likely to me that the policy
issues might need to get more complicated when federating over
international boundaries. Do you have any thoughts on the types of
policies you would want to enforce on, say, US-based researchers, that
might be different from policies for local Korean researchers?

Thus spake Sangjin Jeong on Wed, Nov 11, 2009 at 08:26:03PM +0900:

http://cclab.cnu.ac.kr/~yhchoi/etri/federation.pdf

>
> Any comment/review would be appreciated.
>
> Regards,
> Sangjin
>
> _______________________________________________
> 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

Re: Initial investigation result of federation issues

2009-11-12T05:34:16Z

On Slide 11, you mention different possible levels of federation.

There's a federation going within the US for sites based on the Emulab
software. So far, we have very simple policies for giving access to
members of that federation, but it seems likely to me that the policy
issues might need to get more complicated when federating over
international boundaries. Do you have any thoughts on the types of
policies you would want to enforce on, say, US-based researchers, that
might be different from policies for local Korean researchers?

Thus spake Sangjin Jeong on Wed, Nov 11, 2009 at 08:26:03PM +0900:

> Hello folks,
>
> We have been investigating the federation issues recently and got some
> initial results.
> We plan to prepare a documentation, but it would be helpful to solicit
> reviews/comments
> from the WG before drafting the document. We have requested a
> presentation slot in the
> control framework WG during GEC6, but the agenda is already set and it
> is not sure
> if there will be some time to present this initial result.
>
> So, we would like to solicit comments from the mailing list.
> The slides can be found from http://cclab.cnu.ac.kr/~yhchoi/etri/federation.pdf
>
> Any comment/review would be appreciated.
>
> Regards,
> Sangjin
>
> _______________________________________________
> 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

Initial investigation result of federation issues

2009-11-11T03:26:03Z

Hello folks,

We have been investigating the federation issues recently and got some
initial results.
We plan to prepare a documentation, but it would be helpful to solicit
reviews/comments
from the WG before drafting the document. We have requested a
presentation slot in the
control framework WG during GEC6, but the agenda is already set and it
is not sure
if there will be some time to present this initial result.

So, we would like to solicit comments from the mailing list.
The slides can be found from http://cclab.cnu.ac.kr/~yhchoi/etri/federation.pdf

Any comment/review would be appreciated.

Regards,
Sangjin

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

Control Framework Working Group Meeting GEC5

2009-07-14T11:56:39Z

I'm the new system engineer for the Control Framework Working Group at
the GPO. Here is a draft agenda for the CFWG meeting that will be held
at GEC5 on Wednesday July 22 at 9:00AM. If you have any additional items
for the agenda, please let me know (csmall@...).

- Chris

1. Introduction of new workgroup chair(s). (Larry Peterson, Princeton;
John Wroclawski, ISI)

2. News from the GPO

(a) Status of control framework requirements document. (Christopher
Small, GPO)

(b) Identity management; quick overview of Shibboleth and InCommon.
(Christopher Small, GPO)

3. RSpecs and network stitching

(a) Summary of RSpec discussion at meeting held in Chicago on 6/25/09
(Larry Peterson, Princeton)

(b) Summary of network stitching discussion at meeting held in Chicago
6/25/09

(c) Network stitching in ProtoGENI, (Rob Ricci, University of Utah)

(d) Networkng stitching in ORCA/BEN, (Yufeng Xin, RENCI)

--
Dr. Christopher Small 617.873.6261 (vox)
GENI Program Office www.geni.net 617.873.6091 (fax)
BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138

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

Re: What are GIDs good for?

2009-06-15T22:53:11Z

In theory, I agree to what you are proposing here, but

> The decision we've made for ProtoGENI is that when one validates an
> authentication certificate that claims "URN X is bound to public key
> A",
> the path by which that certificate is traceable to a trust root must
> be
> mirrored by the set of authorities in the URN. (eg. if I have a URN
> that
> contains "geni:us:utah:ricci", the authentication certificate that
> goes
> along with it better be signed by the "geni:us:utah" authority.)

in this specific example, there is authority information buried in the
identifier. How would you deal when you move to a different
organization? Wouldn't your URN change at that point to something like
"geni:us:new_org:ricci"? If so, the problem, I stated in one of the
emails prior to this, of how other sub-systems would know that your id
has changed still persists. And, I think, non-persistent user ids
would result in fragile systems.

One of the ways we deal with this problem is by making the identifiers
non-semantic and trusting the system that binds those identifiers with
authentication information. The trusted system enforces who can change
the information bound (e.g, public key) to those identifiers. To deal
with who is vetting those identifiers, we can have the vetting
entities sign the bound information (public key). The signatures may
be placed along with the public key in the system. So, when parties
try to authenticate a user with id, they would resolve the id and get
the public key and the signatures. The reason the party authenticated
this user successfully, now, is because the party (1) first trusted
the system, (2) verified that the user had the corresponding private
key, and/or (3) verified that one of the signatures is from a trusted
entity.

Although, trusting a system could be a huge thing, we have the luxury
of saying that this system is the Handle System - the one very well
implemented, and vetted by big shots :-)

Thanks.
Giridhar

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

smime.p7s (2K) Download Attachment

Re: What are GIDs good for?

2009-06-15T14:51:20Z

Thus spake Giridhar Manepalli on Mon, Jun 15, 2009 at 10:38:17AM -0400:
> Here, the assumption is that the entity issuing the URN (identifier)
> would be the entity issuing the certificate. How reasonable is this
> assumption?

That's right, and this is an explicit design decision on our part.

The "certificate" here might be better named an "authentication
certificate" since its sole purpose is to bind authentication material
(eg. a public key) to a URN.

In the SFA-style GID, where a public key is part of the identity, the
authentication material is by definition issuable only by the issuer of
the GID (since it's part of the GID).

We we remove the authentication material from the identifier, the
question now becomes "who is able to bind authentication material to
this identifier"? That is, if someone presents, say, a CM, with a URN X
and a statement of the form "URN X is bound to public key A", how do you
decide whether or not to accept that statement? If the CM accepted such
a statement from just anyone, it's trivially easy to hijack an account -
if I want to pretend to be Giridhar, I just make myself a new key pair
and a statement that says it belongs to you, and the CM will happily let
me pretend to be you. We can tighten this up, and say that the statement
has to be traceable through some chain of authorities to a trust root,
but by itself, this still doesn't give us a lot: any authority in the
system can issue such statements for any object. (eg. the US GENI could
hijack accounts "belonging" to its European federate)

The decision we've made for ProtoGENI is that when one validates an
authentication certificate that claims "URN X is bound to public key A",
the path by which that certificate is traceable to a trust root must be
mirrored by the set of authorities in the URN. (eg. if I have a URN that
contains "geni:us:utah:ricci", the authentication certificate that goes
along with it better be signed by the "geni:us:utah" authority.)

Certainly, our choice is not the only possible one, but we think it
strikes a good balance. It hasn't actually added any restrictions that
weren't there in the SFA GID, and it keeps the scope of trust narrow:
the "damage" a buggy, compromised, or malicious authority can cause is
limited to the identifiers that it itself created.

> Further, by extension, would you assume that the same
> entity would issue the credentials, policies, and other forms of
> security information? If the answer is "no", why would you tie the URN
> issuing entity with the certificate issuing entity, and not other
> security related issuers?

Certainly, "no". Credentials, etc. are authorization information, and
the "authentication certificate" is authentication information. So they
definitely should be treated differently. Anybody should be able to give
me resources if they want (authorization), but not everybody should be
able to "change my password" (by binding my URN to a different public
key) (authentication).

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

Re: What are GIDs good for?

2009-06-15T07:38:17Z

Here's an interesting point - one of the properties that appeals to us
about the URNs proposed by the GMOC is that they have a little bit of
semantic information in them - the URN contains the identifier of the
authority that issued the URN. This way, when I get an authentication
certificate that says "URN A is associated with public key X", I can
check to see if the issuer of the certificate is the same entity that
issued URN A. This way, buggy, malicious, or subverted authorities
cannot issue authentication certificates for others' users, components,
etc.

Here, the assumption is that the entity issuing the URN (identifier) would be the entity issuing the certificate. How reasonable is this assumption? Further, by extension, would you assume that the same entity would issue the credentials, policies, and other forms of security information? If the answer is "no", why would you tie the URN issuing entity with the certificate issuing entity, and not other security related issuers? If the answer is "yes", URN issuing entity becomes the central point of failure. Isn't it?

My two cents.

Giridhar

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

smime.p7s (2K) Download Attachment

Re: What are GIDs good for?

2009-06-15T05:58:45Z

The URN proposal and details can be found at:
http://gmoc.grnoc.iu.edu/https/globalnoc/gmoc/file-bin/urn-proposal2.pdf

In short we noticed the problem of bundling of authentication and
identification
in the SFA documents and tried to figure out a way do separate these.

We prefer 'semantic' aware identifiers because otherwise we would require
to build a secure and highly-available resolver service in whose trust
properties
would be appropriate for all applications. (ie the trust chain should be
acceptable
by all participating entities).

Camilo

Robert P Ricci wrote:

> Thus spake Max Ott on Fri, Jun 12, 2009 at 08:55:13PM +1000:
>
>> On 12/06/2009, at 2:15 PM, Giridhar Manepalli wrote:
>>
>>> We extend ProtoGENI's notion (of separating identity and
>>> authentication/authorization) in all of our projects by separating the
>>> identity (of entities) from any of the varying and contextual
>>> attributes/processes. Identifiers, then, are generally opaque and non-
>>> semantic, and may be used to identify any entity/resource
>>> (individuals, documents, processes, etc.).
>>>
>> 'non-semantic' - I like that. Do you have a more detailed write-up
>> available somewhere?
>>
>
> Here's an interesting point - one of the properties that appeals to us
> about the URNs proposed by the GMOC is that they have a little bit of
> semantic information in them - the URN contains the identifier of the
> authority that issued the URN. This way, when I get an authentication
> certificate that says "URN A is associated with public key X", I can
> check to see if the issuer of the certificate is the same entity that
> issued URN A. This way, buggy, malicious, or subverted authorities
> cannot issue authentication certificates for others' users, components,
> etc.
>
> (This can be chained - eg. an authority can create a sub-authority, and
> that sub-authority's identifier includes its "parent"'s identifier. URNs
> share this property with the domain-name looking HRNs that have showed
> up in some places like the SFA doc.)
>
>

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

Re: What are GIDs good for?

2009-06-12T16:18:29Z

Thus spake Max Ott on Fri, Jun 12, 2009 at 08:55:13PM +1000:

> On 12/06/2009, at 2:15 PM, Giridhar Manepalli wrote:
> > We extend ProtoGENI's notion (of separating identity and
> > authentication/authorization) in all of our projects by separating the
> > identity (of entities) from any of the varying and contextual
> > attributes/processes. Identifiers, then, are generally opaque and non-
> > semantic, and may be used to identify any entity/resource
> > (individuals, documents, processes, etc.).
>
> 'non-semantic' - I like that. Do you have a more detailed write-up
> available somewhere?

Here's an interesting point - one of the properties that appeals to us
about the URNs proposed by the GMOC is that they have a little bit of
semantic information in them - the URN contains the identifier of the
authority that issued the URN. This way, when I get an authentication
certificate that says "URN A is associated with public key X", I can
check to see if the issuer of the certificate is the same entity that
issued URN A. This way, buggy, malicious, or subverted authorities
cannot issue authentication certificates for others' users, components,
etc.

(This can be chained - eg. an authority can create a sub-authority, and
that sub-authority's identifier includes its "parent"'s identifier. URNs
share this property with the domain-name looking HRNs that have showed
up in some places like the SFA doc.)

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

Re: What are GIDs good for?

2009-06-12T16:09:18Z

Thus spake Max Ott on Fri, Jun 12, 2009 at 08:29:13PM +1000:

>
> On 12/06/2009, at 9:23 AM, Robert P Ricci wrote:
> >Right, I think the decision that a GID decouples authentication and
> >authorization is pretty clear.
>
> Unfortunately thats is not so clear to me.
>
> In http://www.protogeni.net/trac/protogeni/wiki/AuthImpl it says:
>
> ... each of the principle objects in Protogeni has a unique UUID and
> thus a certificate (GID) associated with it. In most cases these
> certificates are used for identity purposes, not authentication (as in
> an SSL session).
>
> So what does it buy me to have some ID which has been issued by someone?

Yeah, sorry, that page is out of date, written before we started moving
to URNs - we're making that change specifically to separate out
identity and authentication. I'll fix it up.

Once we have our URNs implemented, it will read like this:

"""
... each of the principal objects in Protogeni has a unique URN
associated with it. The authority that issued the URN may issue
certificates binding authentication material to that URN: for example,
to supply the object's public key for authenticating SSL session.
"""

I'm trying to avoid calling our URNs "GIDs", since what exactly a GID
*is* has become so confused. But the point is that the URN is a unique
identifier that I'd use to indicate which component I'm talking about,
which user I'm giving a credential to, etc.

> Later it says: ... When Joe asks his Slice Authority to create this
> new slice, a new credential is formed that includes, among other items:
> Joe's GID (UUID, HRN, email)
> MySlice's GID (UUID, HRN, email)
> A list of tokens

And to be clear, when we move to URN's, this will read:

Joe's URN
MySlice's URN
A list of tokens

> A digital signature (I assume that the digital signature is that of
> the Slice Authority)

Your assumption is correct, I'll clarify it on the page.

> Now that makes sense to me. Someone (the Slice Authority) asserts that
> Joe can perform some action (tokens) on MySlice. Now if Joe request a
> service S to perform an action on the slice, S can now check if the
> requester is the Joe in the assertion,

And with the identity and authentication separated, the way that the S
will check that "the requester is the Joe in the assertion" is that the
assertion will contain Joe's identifier (his URN), and Joe will present
an authentication certificate that says, essentially "Joe's URN (the
same one that was in the credential) is associated with public key X".
This certificate must be signed by the authority that issued Joe's HRN
in the first place (more on that in another mail...), and S will
challenge Joe to be sure he has the associated private key.

> the action is authorized and it
> accepts the authority of the signer of the assertion.

> (To be a
> stickler, I would have expected the (G)ID of the Slice Authority as
> part of that assertion, with the signature for authentication)

The SA's identifier is in the signature, but you're right, it would
probably be good to make 'issuer' a first class field in the credential.

> Now I can potentially chain things by adding an additional assertion
> which transfers the right to use MySlice to Alice. Obviously this
> needs to be signed by Joe and the first assertion may need to include
> permission to do that (delegation).

Yup, and this is exactly what we do:
https://www.protogeni.net/trac/protogeni/wiki/DelegationExample

> But again, what do I need beyond a handle?

I'd say that what you need is an identifier, to avoid the specific
semantics attached to the word "handle" (as seen in the other
sub-thread...)

> The only thing I can think
> of is a reference to a handle's credentials (public key) if it is
> signing something (that's why I was asking about who signed the above).
>
> -max

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

Re: What are GIDs good for?

2009-06-12T08:00:49Z

On Jun 12, 2009, at 6:55 AM, Max Ott wrote:

>
> 'non-semantic' - I like that. Do you have a more detailed write-up
> available somewhere?

A five line summary of the Handle System (HS): What DNS is for
machines, the HS is for digital entities (including machines). And,
this includes the scalability and distribution capability associated
with the DNS. Additionally, the HS provides distributed administration
over each of those identifiers (handles), and the authorization
privileges to edit the associated records are per handle, unlike DNS
where the nameservers are managed by the system admins for all the
associated domain names. The HS does not define what goes into a
handle record, other than what's needed to enable administration per
handle. The applications, GENI apps, for example, which use the
handles define their data model.

Actually, there is a lot of documentation available on http://www.handle.net/
and, fundamentals, on http://www.handle.net/documentation.html

>
> Does that provide anything beyond storage and retrieval?

As mentioned above, the HS provides distributed administration by
authenticating (PKI) and authorizing the entity who tries to perform
such an administration. In essence, if you (and your organization
people) can create a handle, associate a record of information with
that handle. The HS ensures who-can-write, who-can-read, etc. The
default is owners can write, everyone else can see, but this is
configurable (by virtue of which, for instance, you can enable
everyone-can-write, but owners-can-read - not sure why you would want
to do that, though).

However, if you want to query over the attributes defined in a handle
record and get back the handle (that is, perform reverse lookup), then
registries are the way to go. We use the registry, along with the HS,
for indexing and searching capability.

>
> Wouldn't we also ned to capture who added those attributes, or more
> precisely who claims that an identity has a certain attribute. The
> old 'Max broke the window - says who?'
>

Yes, and the HS takes care of it. But, if you need more than what the
HS provides, you can always define what goes into a record and
configure the HS clients to understand your record of information
associated with your set of handles.

>
> Exactly. And remember, a certificate is really just an assertion
> that someone claims that this is the public key for a certain entity.

True.

> I very much think so. Right now, we all pretty much work in our own
> universe and things already work for the use cases we support. But
> things get hairy pretty quickly when some of them collide,
> especially when lawyers are involved or different usage policies
> need to be accommodated. I'm not suggesting that we need to fully
> define how we deal with this, but the architecture at least should
> give us a clear idea where we would need to deal with that 'mess'
> and how to pass relevant information around. Another reason to have
> a closer look at related standards and concepts, such as PEP,
> PDP, ... We all have them implicit somewhere anyway and I'm sure we
> all have a few ugly hacks to deal with 'special cases'.

It might be of interest to you that we started down the federation of
clearinghouses path to federate from different clusters. We came up
with a preliminary data model for the clearinghouse records and is
made available here: (http://groups.geni.net/geni/attachment/wiki/DigitalObjectRegistry/FederatedClearinghouse.pdf
). We'll be using the registry with the HS, aka Digital Object
Registry, to perform this federation. ProtoGENI was very collaborative
and let us federate their data into our federation. But the real test
to our data model, and our approach in general, is when we federate
from a second and perhaps the third cluster. But right now, we don't
have that good problem.

Cheers,
Giridhar

>
> -max
>

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

smime.p7s (2K) Download Attachment

Re: What are GIDs good for?

2009-06-12T04:02:43Z

On 12/06/2009, at 9:23 AM, Robert P Ricci wrote:
> Right, I think the decision that a GID decouples authentication and
> authorization is pretty clear.

Unfortunately thats is not so clear to me.

In http://www.protogeni.net/trac/protogeni/wiki/AuthImpl it says:

... each of the principle objects in Protogeni has a unique UUID and
thus a certificate (GID) associated with it. In most cases these
certificates are used for identity purposes, not authentication (as in
an SSL session).

So what does it buy me to have some ID which has been issued by someone?

Later it says: ... When Joe asks his Slice Authority to create this
new slice, a new credential is formed that includes, among other items:
Joe's GID (UUID, HRN, email)
MySlice's GID (UUID, HRN, email)
A list of tokens
A digital signature (I assume that the digital signature is that of
the Slice Authority)

Now that makes sense to me. Someone (the Slice Authority) asserts that
Joe can perform some action (tokens) on MySlice. Now if Joe request a
service S to perform an action on the slice, S can now check if the
requester is the Joe in the assertion, the action is authorized and it
accepts the authority of the signer of the assertion. (To be a
stickler, I would have expected the (G)ID of the Slice Authority as
part of that assertion, with the signature for authentication)

Now I can potentially chain things by adding an additional assertion
which transfers the right to use MySlice to Alice. Obviously this
needs to be signed by Joe and the first assertion may need to include
permission to do that (delegation).

But again, what do I need beyond a handle? The only thing I can think
of is a reference to a handle's credentials (public key) if it is
signing something (that's why I was asking about who signed the above).

-max

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

Fwd: What are GIDs good for?

2009-06-12T04:00:33Z

On 12/06/2009, at 2:15 PM, Giridhar Manepalli wrote:
> We extend ProtoGENI's notion (of separating identity and
> authentication/authorization) in all of our projects by separating the
> identity (of entities) from any of the varying and contextual
> attributes/processes. Identifiers, then, are generally opaque and non-
> semantic, and may be used to identify any entity/resource
> (individuals, documents, processes, etc.).

'non-semantic' - I like that. Do you have a more detailed write-up
available somewhere?

> However, we associate
> related attributes (such as public key, credential set, associated
> policy, personal preferences, associated URL for the entity), aka
> record, by registering those identifiers and corresponding (mutable)
> records in a system.

Does that provide anything beyond storage and retrieval?

Wouldn't we also ned to capture who added those attributes, or more
precisely who claims that an identity has a certain attribute. The old
'Max broke the window - says who?'

>
For example, if public
keys are used as identifiers for users, what if the private way of a
> particular user was compromised? Wouldn't the identifier (public key)
> for the user change when a new pair of keys are generated, and, if so,
> how would this translate into trust and other aspects?

Exactly. And remember, a certificate is really just an assertion that
someone claims that this is the public key for a certain entity.

> In any case, I
> think, this issue needs to be addressed at this stage to be able to
> perform federations, for example, as Max Ott hinted.

I very much think so. Right now, we all pretty much work in our own
universe and things already work for the use cases we support. But
things get hairy pretty quickly when some of them collide, especially
when lawyers are involved or different usage policies need to be
accommodated. I'm not suggesting that we need to fully define how we
deal with this, but the architecture at least should give us a clear
idea where we would need to deal with that 'mess' and how to pass
relevant information around. Another reason to have a closer look at
related standards and concepts, such as PEP, PDP, ... We all have them
implicit somewhere anyway and I'm sure we all have a few ugly hacks to
deal with 'special cases'.

-max

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

Re: What are GIDs good for?

2009-06-12T03:55:13Z

Re: What are GIDs good for?

2009-06-11T21:15:04Z

We extend ProtoGENI's notion (of separating identity and
authentication/authorization) in all of our projects by separating the
identity (of entities) from any of the varying and contextual
attributes/processes. Identifiers, then, are generally opaque and non-
semantic, and may be used to identify any entity/resource
(individuals, documents, processes, etc.). However, we associate
related attributes (such as public key, credential set, associated
policy, personal preferences, associated URL for the entity), aka
record, by registering those identifiers and corresponding (mutable)
records in a system. Now, any interested party, (an authentication
system, or authorizing system, or policy evaluation system), may be
able to get related information for any identifier by resolving that
identifier using the registered system. The idea of separating
identifiers from any of the varying attributes, we think, results in
longevity of the projects that import this concept and eliminates some
of the management issues at an early stage. For example, if public
keys are used as identifiers for users, what if the private way of a
particular user was compromised? Wouldn't the identifier (public key)
for the user change when a new pair of keys are generated, and, if so,
how would this translate into trust and other aspects? In any case, I
think, this issue needs to be addressed at this stage to be able to
perform federations, for example, as Max Ott hinted.

FYI:

The resolvable identifiers, aka Handles, and the registration system,
aka the Handle System, are defined in RFCs 3650, 3651 and 3652. The
Handle System is being used to create DOIs by major publishers (IEEE,
etc.) and, among others, is also used in information management
projects in military (ADL-R).

Giridhar

On Jun 11, 2009, at 7:23 PM, Robert P Ricci wrote:

> Right, I think the decision that a GID decouples authentication and
> authorization is pretty clear. The other big decision point is whether
> they should couple authorization and identity. As written in the SFA
> and
> other places, they conflate the two by using a public key as part of
> the
> identity. We're going down a route that separates the two.

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

smime.p7s (2K) Download Attachment

Re: What are GIDs good for?

2009-06-11T16:23:32Z

Thus spake Larry Peterson on Thu, Jun 11, 2009 at 10:33:35AM -0400:
> I think the SFA design also decouples authentication from
> authorization. The GID is a certificate that identifies an entity,
> chained back to someone I trust. We can quibble about the
> definition of the GID (e.g., whether it needs a UUID or a public
> key is sufficient to uniquely identify the entity), but that's the
> general idea.

Right, I think the decision that a GID decouples authentication and
authorization is pretty clear. The other big decision point is whether
they should couple authorization and identity. As written in the SFA and
other places, they conflate the two by using a public key as part of the
identity. We're going down a route that separates the two.

The GMOC project has put together a proposal based on URNs (RFC 2141),
which are used solely for identification purposes. We're in the process
of implementing it. (I'd link to their doc, but I don't see it up on
their website - I'll ask them about it):
http://gmoc.grnoc.iu.edu/gmoc/index.html

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

Re: What are GIDs good for?

2009-06-11T07:33:35Z

I think the SFA design also decouples authentication from
authorization. The GID is a certificate that identifies an entity,
chained back to someone I trust. We can quibble about the
definition of the GID (e.g., whether it needs a UUID or a public
key is sufficient to uniquely identify the entity), but that's the
general idea.

Authorization requires a credential, which also includes a set
of rights this particular principal is granted. The server inspects
this credential before authorizing the operation.

As for SAML, it's a perfectly reasonable thing to use. As the
SFA was being hashed out, we tended to shy away from
heavy-weight mechanisms that might warp the design in some
way, but using SAML in a prototype would be a reasonable thing
to do.

Larry

On Thu, Jun 11, 2009 at 9:12 AM, Max Ott<Max.Ott@...> wrote:

> Folks,
>
> We have been spending a lot of time recently working through
> federation issues, looking at the design notes from other control
> frameworks, standards, ... and getting more and more confused :)
>
> While my primary confusion really centers on the slice manager - whose
> exact role I understand less and less, we got specifically stuck on
> the GID today and all the certificate chains attached to it. I read
> the Ricci's and Leigh's notes on it, and Thierry and I tried to work
> through the geniwrapper code.
>
> Anyway, what do we want to achieve? We have resources, we users who
> want to use them and we have control frameworks which stand in the
> middle. Or maybe in a more generic way, we have entities which want to
> perform actions on other entities and somebody needs to authorize that.
>
> SAML very clearly differentiates between authorization and
> authentication and I'm wondering if we make the same clean
> separation. Maybe a different question would be, why aren't we using
> standard solutions, such as SAML? I know they often big and cover a
> lot of other stuff, but the basic concepts seem to be sound.
>
> So what is wrong with using 'normal' identifiers and attach assertions
> - what the object is allowed to do, who can do what with it, for how
> long, ... Assertions themselves can be signed and can refer to other
> assertions from which they get the authority to make the assertions
> they make. Signatures are verified the standard way back to a well
> known anchor (I know we already do that), and assertions provide the
> chain along legal agreements, or to resource allocation policies or
> 'cost centers'.
>
> This way, I can break the necessary information I need to make a
> decision at various places into individual pieces; can link them by
> URLs; or pack them all together into standard messaging formats such
> as MIME/S or PGP (and the many existing toolkits)
>
> I'm not a security expert and I may miss something obvious, but I have
> a really hard time seeing how the current architecture will cleanly
> accommodate a federated world with changing legal and policy
> requirements.
>
> Thanks,
>
> -max
>
>
> _______________________________________________
> 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

What are GIDs good for?

2009-06-11T06:12:02Z

Folks,

We have been spending a lot of time recently working through
federation issues, looking at the design notes from other control
frameworks, standards, ... and getting more and more confused :)

While my primary confusion really centers on the slice manager - whose
exact role I understand less and less, we got specifically stuck on
the GID today and all the certificate chains attached to it. I read
the Ricci's and Leigh's notes on it, and Thierry and I tried to work
through the geniwrapper code.

Anyway, what do we want to achieve? We have resources, we users who
want to use them and we have control frameworks which stand in the
middle. Or maybe in a more generic way, we have entities which want to
perform actions on other entities and somebody needs to authorize that.

SAML very clearly differentiates between authorization and
authentication and I'm wondering if we make the same clean
separation. Maybe a different question would be, why aren't we using
standard solutions, such as SAML? I know they often big and cover a
lot of other stuff, but the basic concepts seem to be sound.

So what is wrong with using 'normal' identifiers and attach assertions
- what the object is allowed to do, who can do what with it, for how
long, ... Assertions themselves can be signed and can refer to other
assertions from which they get the authority to make the assertions
they make. Signatures are verified the standard way back to a well
known anchor (I know we already do that), and assertions provide the
chain along legal agreements, or to resource allocation policies or
'cost centers'.

This way, I can break the necessary information I need to make a
decision at various places into individual pieces; can link them by
URLs; or pack them all together into standard messaging formats such
as MIME/S or PGP (and the many existing toolkits)

I'm not a security expert and I may miss something obvious, but I have
a really hard time seeing how the current architecture will cleanly
accommodate a federated world with changing legal and policy
requirements.

Thanks,

-max

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

Re: clearinghouses (or not)

2009-04-20T11:32:30Z

On Mon, Apr 20, 2009 at 10:55:24AM -0400, Aaron Falk wrote:
> Ted-
>
> This is quite interesting and gives me a much better idea of what TIED
> is trying to accomplish but left me with several questions (inline).

Let me also point you to
http://fedd.isi.deterlab.net/trac
particularly
http://fedd.isi.deterlab.net/trac/wiki/FeddAbout
and
http://fedd.isi.deterlab.net/trac/wiki/FeddPubs

Those go into more detail than these messages can. Of course, TIED and
the DFA are moving targets and I'm happy to clarify.

>
> Ted Faber wrote:
> >
> > I see John's talked a little about the authorization model, but there's
> > one more sublety to the TIED world, even under the current model, that
> > may be interesting. The following is how it works today.
> >
> > Who one could talk to about a misbehaving experiment depends on who one
> > is and what action they want to take. When a federated experiment is
> > created in TIED, the federator (fedd) requests access from the federants
> > based on a global name and attribute space. Right now the attributes in
> > that space are <testbed, project, user> - extended from the Emulab model
> > - but they're a separate space from the local federants' project space.
> > When a federant grants access it maps the incoming sub-experiment into
> > its local <project, user> space. Within that local space there may be a
> > bunch of relevant data about the real-world generator of that project
> > that is local to the federant.
>
> The "real-world generator of that project" is the researcher. (Right?)

Yep.

> How does the federant get this information? The researcher's access is
> via the federator. (Right?) Suppose a federant is interested in the
> attribute that states whether a user is staff, student, or faculty. How
> does it learn that about a user?

Federators and federants can agree on the meaning of certain attributes.
In the current <testbed, project, user> layout the kind of attributes
you're thinking of could be encoded as projects. Don't get too caught
up in the "project" name. A "testbed" in this name space is a
federating entity, a "project" is a group of users that share an
attribute, and a "user" is an individual. The names are an artifact of
generalizing the Emulab namespace (and probably my limited understanding
of that name space).

So if federating entity A trusts federating entity B to identify faculty
members by putting them in a "faculty" group, that's how the
communication above happens. Note that the entity asserting that a user
is a faculty person does not need to be associated with a physical
groups of resources. Some central GENI site could do that coordination,
even if it's not managing a testbed (or running Emulab software).
That's to say that fedd will run on your desktop for the purpose of
getting resources from other testbeds and coordinating experiments. I
think that's to say it can act as a slice manager.

Our plans to got to ABAC are motivated by that system being able to
express more complex authorization relations. Under the simple system
above, scaling is limted by the number of "testbeds" a given resource
allocator trusts. ABAC lets me split that up more by saying testbed A
trusts facility F to certify faculty-asserting testbeds. Testbed A
trusts the faculty "group" (or attribute) from any testbed that facility
F trusts. That delegation improves scalability, and is only one ABAC
example.

>
> > On the other side the federator may have
> > a collection of real world information about the creator of the
> > federated experiment. Access to those local stores of information are
> > controlled by their respective owners.
> >
> > To be concrete about it, consider an experimenter creating a federated
> > experiment across two testbeds, T1 and T2, using a federator located at
> > T3. The experimenter makes the request to T3, and gives a global
> > credential to identify themselves (this is an X.509 cert that's acting
> > as one of our global names (a fedid) - more at
> > http://fedd.isi.deterlab.net/trac/wiki/FeddAbout#AccessControl ). Based
> > on that name the fedd at T3 can assert to the other testbeds that, for
> > example, this is user "faber" in the projects "federators" and
> > "operators" on testbed "T3."
> >
> > Let T1 be a very loosely controlled testbed that allocates resources for
> > federated experiments out of its "loose_federation" project with a generic
> > user with no real world identification attached. Any T3 user is allowed
> > access to that group and the T3 fedd need only tell the T1 testbed that a
> > T3 user is requesting resources and T1 will return the information
> > necessary to allocate an experiment in that project on T1.
> >
> > Let T2 only allow experimenters with the "operators" project attribute
> > asserted on T3 to allocate resources and those resources are mapped to
> > its "tracable_federation" project. That T2 project has the real world
> > information of a responsible T3 principal associated with it. This
> > exchange of information was done out of band as a prerequisite for
> > federation.
> >
>
> Does this require that every institution with users run fedd? If so, I
> think that I understand how to answer my question above by creating
> 'projects' for staff, students, and staff (since that distinction is
> important to me).

To work with TIED you have to support fedd's interfaces. We don't much
care if you run our code. The interface definitions are here:
http://fedd.isi.deterlab.net/trac/browser/fedd/trunk/wsdl
There are comments, etc. there and the papers help understand it as
well, but I'm happy to work through the details with people.

> But it seems that having a small and useful (albeit
> extensible) set of attributes defined early will be important since it
> sounds like every federator needs to understand every attribute required
> by a federant. (Right?)

If a federant requires an attribute a federator has never heard of in
order to grant access, well, there's an obvious problem there. But it's
possible for a federator and federant to carry on successful
negotiations when the federator knows a subset of the attributes that
the federant understands.

It seems reasonable to me that testbeds/federants would grant some basic
resource allocation to users with minimal information. That might not
be the way it happens in practice.

> It seems there is some risk that this could
> become unmanageable if federants were inventing lots of new attributes
> (say, with poorly defined or overlapping definitions).

This is possible, of course; I think it's somewhat unlikely.

The purpose of attributes are to allow resource sharing. I think people
motivated to share resources will come up with sets of vaild, meaningful
attributes and will arrive at de facto standards. I also think the GPO
and the working groups provide a place for discussions on those
standards.

Notice that the set of attributes that most providers understand when
asserted (the attribute ontology) is different from the trust in those
assertions. Those need to be separated, at least architecturally. I
mention it because InCommon merges the two.

>
> > A more diligent testbed might map the global user identity to a local
> > user identity as well. Similarly, based on which attributes the T3 fedd
> > was able to assert, the local testbed may pick the local project from a
> > set with different information and rights attached - e.g., operators can
> > allocate more nodes.
> >
> > Because our experimenter has the relevant attributes (and assuming the
> > resources are available and allocated) the T3 fedd will be able to
> > create a federated experiment, which it will name and associate with the
> > experimenter.
> >
> > Notice that based on the global attributes (testbed and operator),
> > sub-experiments are associated with differnet local projects
> > (loose_federation and tracable_federation) on each testbed.
> >
>
> I don't quite get this. "Loose federation" and "traceable federation"
> seem like authorization policies, not projects. I think you are using
> 'project' in a new way. Can you give a definition? (Or just clarify?)

"Loose_federation" and "traceable_federation" are Emulab groups on the
local testbeds the names are supposed to be illustrative, but nothing
else. I could have called them "fred" and "ethel" but I was hoping to
make things easier to follow. (Apparently that didn't work out...)

In Emulab, a user's right to allocate resources is bound to their
membership in a project (and groups within that project, but I'm
simiplifying here). Because a federator doesn't know the local
allocation policies and permissions in detail and the local federant
similarly needn't know the global policies. there's a step where we
shift from the federator saying "here's what you wanted to know about
this user" into the local testbed saying "this user has the following
rights in my world". Mapping from the global name/attribute space into
a local Emulab project is how we implement that mapping now.

Alos associated with a project is a set of data about the person who was
given the rights to that project (phone #, e-mail address, etc.). In
addition to binding the rights to the user, it binds the contact
information. See below.

>
> > Now if the experiment begins doing bad things, the T1 and T2 admins have
> > access to different information. The T1 admins only know something in
> > the "loose_federation" project is acting up. They can take action on
> > their sub-part or make a request to the T3 fedd for more information
> > about the experiment or the experimenter (though that interface isn't
> > yet available) or to terminate the experiment as a whole (that one is).
> > Exactly how the fedd will react to those requests is dependent on the
> > agreements between T1 and T3, but the T1 admins can always shut down
> > their sub-experiment.
> >
> > On T2 the situation is somewhat different. Because they gathered
> > information as a prerequisite to federation (not to instantiating this
> > experiment in particular, though), they have more local information to
> > work with as far as who they can talk to.
>
> Meaning, they know more about the identity of the user? Or do you mean
> something else?

T2 may have gotten infromation about the particular users that they'll
allow on. More likely, they got enough information to track down a
particular user in the event of a problem. For example, a tightly run
textbed might get the name and phone of every student who would
federate; a more relaxed testbed might get the phone number of a
responsible member from each research team; a more relaxed one might get
the phone number of the folks running the federator.

This is another spot where it helps to understand the Emulab model a
little, to get our intuition. An Emulab project has a leader (think
research PI) who can add access to other users (think graduate
researchers). The testbed operators (DETER, Emulab) set rules about
what kind of information a project leader must provide and how well it's
vetted. Similarly, the information for each user is vetted by the PI
(and made available to testbed operators).

If an experiment goes awry on DETER (which is the testbed I heve
experience with), we tend to try to contact the user who started the
experiment firts, and if that fails, talk to the project leader. We
understand that user information may be less vetted that leader
information (which we vet ourselves, pretty carefully). The trade off
is that we don't have to be involved with the hundreds of user
authorizations, but when an experiment goes awry we may not have
immediate access to the person who started it (though we have a
connection to someone who does have access to them).

It's the same game in the federated world. The more information a
federant requires for a given allocation, the more directly they can
address misbehavior, but the more interactions there need to be when
federating.

Our point isn't to take a position on whether federants should gather a
lot of information or a little. Our architecture allows both, and we'll
let the players decide.

>
> > All the options of contacting
> > the T3 fedd are also open, as are the options of unilateral action on
> > their own resources.
> >
> > This setup allows the testbeds to make their own decisions about how
> > much information they need as federation prerequisites and what range of
> > accountability they require.
> >
>
> So, this sounds quite interesting and cool. Nevertheless, if every
> institution runs a fedd, I'm concerned about the number of agreements
> involved. Seems like this flexibility could make it hard to grow the
> number of institutions who can use GENI or to have "most" components
> available to "most" users. Am I missing something?

You have the limits of the current implementation clear. That's why I'm
quick to point out the shift to ABAC, which will scale better.

--
Ted Faber
http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG

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

attachment0 (202 bytes) Download Attachment

Re: clearinghouses (or not)

2009-04-20T07:55:24Z

Ted-

This is quite interesting and gives me a much better idea of what TIED
is trying to accomplish but left me with several questions (inline).

Ted Faber wrote:

>
> I see John's talked a little about the authorization model, but there's
> one more sublety to the TIED world, even under the current model, that
> may be interesting. The following is how it works today.
>
> Who one could talk to about a misbehaving experiment depends on who one
> is and what action they want to take. When a federated experiment is
> created in TIED, the federator (fedd) requests access from the federants
> based on a global name and attribute space. Right now the attributes in
> that space are <testbed, project, user> - extended from the Emulab model
> - but they're a separate space from the local federants' project space.
> When a federant grants access it maps the incoming sub-experiment into
> its local <project, user> space. Within that local space there may be a
> bunch of relevant data about the real-world generator of that project
> that is local to the federant.

The "real-world generator of that project" is the researcher. (Right?)
How does the federant get this information? The researcher's access is
via the federator. (Right?) Suppose a federant is interested in the
attribute that states whether a user is staff, student, or faculty. How
does it learn that about a user?

> On the other side the federator may have
> a collection of real world information about the creator of the
> federated experiment. Access to those local stores of information are
> controlled by their respective owners.
>
> To be concrete about it, consider an experimenter creating a federated
> experiment across two testbeds, T1 and T2, using a federator located at
> T3. The experimenter makes the request to T3, and gives a global
> credential to identify themselves (this is an X.509 cert that's acting
> as one of our global names (a fedid) - more at
> http://fedd.isi.deterlab.net/trac/wiki/FeddAbout#AccessControl ). Based
> on that name the fedd at T3 can assert to the other testbeds that, for
> example, this is user "faber" in the projects "federators" and
> "operators" on testbed "T3."
>
> Let T1 be a very loosely controlled testbed that allocates resources for
> federated experiments out of its "loose_federation" project with a generic
> user with no real world identification attached. Any T3 user is allowed
> access to that group and the T3 fedd need only tell the T1 testbed that a
> T3 user is requesting resources and T1 will return the information
> necessary to allocate an experiment in that project on T1.
>
> Let T2 only allow experimenters with the "operators" project attribute
> asserted on T3 to allocate resources and those resources are mapped to
> its "tracable_federation" project. That T2 project has the real world
> information of a responsible T3 principal associated with it. This
> exchange of information was done out of band as a prerequisite for
> federation.
>

Does this require that every institution with users run fedd? If so, I
think that I understand how to answer my question above by creating
'projects' for staff, students, and staff (since that distinction is
important to me). But it seems that having a small and useful (albeit
extensible) set of attributes defined early will be important since it
sounds like every federator needs to understand every attribute required
by a federant. (Right?) It seems there is some risk that this could
become unmanageable if federants were inventing lots of new attributes
(say, with poorly defined or overlapping definitions).

> A more diligent testbed might map the global user identity to a local
> user identity as well. Similarly, based on which attributes the T3 fedd
> was able to assert, the local testbed may pick the local project from a
> set with different information and rights attached - e.g., operators can
> allocate more nodes.
>
> Because our experimenter has the relevant attributes (and assuming the
> resources are available and allocated) the T3 fedd will be able to
> create a federated experiment, which it will name and associate with the
> experimenter.
>
> Notice that based on the global attributes (testbed and operator),
> sub-experiments are associated with differnet local projects
> (loose_federation and tracable_federation) on each testbed.
>

I don't quite get this. "Loose federation" and "traceable federation"
seem like authorization policies, not projects. I think you are using
'project' in a new way. Can you give a definition? (Or just clarify?)

> Now if the experiment begins doing bad things, the T1 and T2 admins have
> access to different information. The T1 admins only know something in
> the "loose_federation" project is acting up. They can take action on
> their sub-part or make a request to the T3 fedd for more information
> about the experiment or the experimenter (though that interface isn't
> yet available) or to terminate the experiment as a whole (that one is).
> Exactly how the fedd will react to those requests is dependent on the
> agreements between T1 and T3, but the T1 admins can always shut down
> their sub-experiment.
>
> On T2 the situation is somewhat different. Because they gathered
> information as a prerequisite to federation (not to instantiating this
> experiment in particular, though), they have more local information to
> work with as far as who they can talk to.

Meaning, they know more about the identity of the user? Or do you mean
something else?

> All the options of contacting
> the T3 fedd are also open, as are the options of unilateral action on
> their own resources.
>
> This setup allows the testbeds to make their own decisions about how
> much information they need as federation prerequisites and what range of
> accountability they require.
>

So, this sounds quite interesting and cool. Nevertheless, if every
institution runs a fedd, I'm concerned about the number of agreements
involved. Seems like this flexibility could make it hard to grow the
number of institutions who can use GENI or to have "most" components
available to "most" users. Am I missing something?

--aaron

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

Re: clearinghouses (or not)

2009-04-20T06:53:36Z

Hi Max,

>From the thread, I think there actually was a general agreement on a
group of functional building blocks (of course, there were a couple of
sub-threads debating different things), that correspond more or less
to what you describe. The primary debate from my perspective seemed
to be over how these functions get divided up between the different
principals in GENI (Clearinghouse, AM, etc.). I won't rehash the
debate (lest I risk heating this thread up again).

-David

On Mon, Apr 20, 2009 at 9:36 AM, Max Ott <max.ott@...> wrote:

> My head is spinning after reading the entire thread in one go. I
> wonder if we can agree on some basic functional blocks we need to make
> this work and on which we can build on to allow for more and more
> complex scenarios.
>
> In the simplest case we have experimenters wanting resources which are
> managed by aggregates (I know that's already an assumption but I
> didn't see much opposition to that).
>
> There needs to be some mechanism to discover which aggregates can
> provide a set of resources (I specifically don't require a list of
> available resources. However we need a mechanism to describe
> resources - the requirements for that may differ between different
> actors )
>
> There needs to be a mechanism for requesting resources from
> aggregates. At this stage someone needs to decide:
> a) Is the requester 'allowed' to make the request. Basically is there
> some kind of 'link' between the aggregate and the requester which for
> most of our facilities includes some kind of legal agreement and some
> delegation model.
> b) should the request be granted. Basically a resource allocation
> decision based on some policy.
>
> As this decision has some lasting effects we need some kind of entity
> to represent this session. I assume this is the famous 'slice' which
> seems to be mean different things to different people. Not sure if it
> is really much more than a handle for different entities to hang
> different things onto it. But it seem to have acquired some mythical
> status by now :)
>
> What else do we need?
>
> * A way for an experimenter to be notified when a resource is
> available, how to access it, manage and control it, or is misbehaving
> (e.g. dying), or is being taken away (because we have to give a demo
> to someone important :)
>
> * A way to add or remove resources from the session (alright it's
> called a slice around here)
>
> - A way for somebody else to complain that a certain resource seems to
> be doing something bad
>
> * The famous 'red shining button' to shutdown all resources belonging
> to a slice within an aggregate (as long as presenting the right
> credentials and like Larry I'm arguing for this to be a aggregate
> level issue)
>
> * A way to investigate the state of an aggregate and its resources and
> infrastructure (given the right credentials) - this is not fundamental
> (but IMHO essential)
>
> ----
>
> Anything else fundamentally missing? I'm basically interested in
> clearly separating control flows, from trust chains, from policy based
> decision points.
>
> After after all we need to make it as painless as possible for
> experimenters to find the resources the need for their experiments as
> well as for aggregate owners to feel comfortable to join a federated
> world (and their lawyers to let them).
>
> Cheers,
>
> -max
>
>
>
>
>
>
> _______________________________________________
> 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

Re: clearinghouses (or not)

2009-04-20T06:36:47Z

My head is spinning after reading the entire thread in one go. I
wonder if we can agree on some basic functional blocks we need to make
this work and on which we can build on to allow for more and more
complex scenarios.

In the simplest case we have experimenters wanting resources which are
managed by aggregates (I know that's already an assumption but I
didn't see much opposition to that).

There needs to be some mechanism to discover which aggregates can
provide a set of resources (I specifically don't require a list of
available resources. However we need a mechanism to describe
resources - the requirements for that may differ between different
actors )

There needs to be a mechanism for requesting resources from
aggregates. At this stage someone needs to decide:
a) Is the requester 'allowed' to make the request. Basically is there
some kind of 'link' between the aggregate and the requester which for
most of our facilities includes some kind of legal agreement and some
delegation model.
b) should the request be granted. Basically a resource allocation
decision based on some policy.

As this decision has some lasting effects we need some kind of entity
to represent this session. I assume this is the famous 'slice' which
seems to be mean different things to different people. Not sure if it
is really much more than a handle for different entities to hang
different things onto it. But it seem to have acquired some mythical
status by now :)

What else do we need?

* A way for an experimenter to be notified when a resource is
available, how to access it, manage and control it, or is misbehaving
(e.g. dying), or is being taken away (because we have to give a demo
to someone important :)

* A way to add or remove resources from the session (alright it's
called a slice around here)

- A way for somebody else to complain that a certain resource seems to
be doing something bad

* The famous 'red shining button' to shutdown all resources belonging
to a slice within an aggregate (as long as presenting the right
credentials and like Larry I'm arguing for this to be a aggregate
level issue)

* A way to investigate the state of an aggregate and its resources and
infrastructure (given the right credentials) - this is not fundamental
(but IMHO essential)

----

Anything else fundamentally missing? I'm basically interested in
clearly separating control flows, from trust chains, from policy based
decision points.

After after all we need to make it as painless as possible for
experimenters to find the resources the need for their experiments as
well as for aggregate owners to feel comfortable to join a federated
world (and their lawyers to let them).

Cheers,

-max

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

Re: clearinghouses (or not)

2009-04-17T18:50:54Z

On Fri, Apr 17, 2009 at 11:34:46AM -0600, Robert P Ricci wrote:

> To be a little more concrete - in PlanetLab, every slice is associated
> with a 'site', so I know if the slice utah_robsbadslice is sending
> apparent attack traffic, hogging resources, or whatever, I can talk to
> Utah to complain about it. (I could talk to the slice's creator too, but
> if s/he's behaving badly, I need to be able to talk to whoever has taken
> responsibility for her/him). Similarly, in Emulab, every experiment is
> associated with a "project", so I know I can talk to the person who's
> registered as the head of the project that experiment is a part of if I
> have any issues with the experiment. The TIED project uses the same
> structure, as far as I know, as Emulab, since that's what it's built on.
> I believe ORBIT has some kind of similar structure, and I don't know
> about ORCA.

I see John's talked a little about the authorization model, but there's
one more sublety to the TIED world, even under the current model, that
may be interesting. The following is how it works today.

Who one could talk to about a misbehaving experiment depends on who one
is and what action they want to take. When a federated experiment is
created in TIED, the federator (fedd) requests access from the federants
based on a global name and attribute space. Right now the attributes in
that space are <testbed, project, user> - extended from the Emulab model
- but they're a separate space from the local federants' project space.
When a federant grants access it maps the incoming sub-experiment into
its local <project, user> space. Within that local space there may be a
bunch of relevant data about the real-world generator of that project
that is local to the federant. On the other side the federator may have
a collection of real world information about the creator of the
federated experiment. Access to those local stores of information are
controlled by their respective owners.

To be concrete about it, consider an experimenter creating a federated
experiment across two testbeds, T1 and T2, using a federator located at
T3. The experimenter makes the request to T3, and gives a global
credential to identify themselves (this is an X.509 cert that's acting
as one of our global names (a fedid) - more at
http://fedd.isi.deterlab.net/trac/wiki/FeddAbout#AccessControl ). Based
on that name the fedd at T3 can assert to the other testbeds that, for
example, this is user "faber" in the projects "federators" and
"operators" on testbed "T3."

Let T1 be a very loosely controlled testbed that allocates resources for
federated experiments out of its "loose_federation" project with a generic
user with no real world identification attached. Any T3 user is allowed
access to that group and the T3 fedd need only tell the T1 testbed that a
T3 user is requesting resources and T1 will return the information
necessary to allocate an experiment in that project on T1.

Let T2 only allow experimenters with the "operators" project attribute
asserted on T3 to allocate resources and those resources are mapped to
its "tracable_federation" project. That T2 project has the real world
information of a responsible T3 principal associated with it. This
exchange of information was done out of band as a prerequisite for
federation.

A more diligent testbed might map the global user identity to a local
user identity as well. Similarly, based on which attributes the T3 fedd
was able to assert, the local testbed may pick the local project from a
set with different information and rights attached - e.g., operators can
allocate more nodes.

Because our experimenter has the relevant attributes (and assuming the
resources are available and allocated) the T3 fedd will be able to
create a federated experiment, which it will name and associate with the
experimenter.

Notice that based on the global attributes (testbed and operator),
sub-experiments are associated with differnet local projects
(loose_federation and tracable_federation) on each testbed.

Now if the experiment begins doing bad things, the T1 and T2 admins have
access to different information. The T1 admins only know something in
the "loose_federation" project is acting up. They can take action on
their sub-part or make a request to the T3 fedd for more information
about the experiment or the experimenter (though that interface isn't
yet available) or to terminate the experiment as a whole (that one is).
Exactly how the fedd will react to those requests is dependent on the
agreements between T1 and T3, but the T1 admins can always shut down
their sub-experiment.

On T2 the situation is somewhat different. Because they gathered
information as a prerequisite to federation (not to instantiating this
experiment in particular, though), they have more local information to
work with as far as who they can talk to. All the options of contacting
the T3 fedd are also open, as are the options of unilateral action on
their own resources.

This setup allows the testbeds to make their own decisions about how
much information they need as federation prerequisites and what range of
accountability they require.

--
Ted Faber
http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG

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

attachment0 (202 bytes) Download Attachment

Re: clearinghouses (or not)

2009-04-17T18:26:10Z

Thus spake Aaron Falk on Fri, Apr 17, 2009 at 03:38:34PM -0400:

> > Yes, every university should have a slice authority -- I can't know
> > whether to approve Joe Random Student's slice; only you do. That
> > does not mean every university runs their own registry, which
> > records trust relationships created by slice authorities. In our version,
> > PLC runs a registry on behalf of all US universities and PLE runs a
> > registry on behalf of all European universities. If one day MIT asks
> > to run their own sub-registry, we ought to be able to support that, but
> > we don't require it.
>
> OK, this helps. The SFA says the slice authority is a principal. But
> it's also software, right?

Yeah, this confusion has existed for a long time - I like to think of it
as the code that's acting on behalf of a (particular) principal.

> How is an SA bootstrapped? I.e., who
> vouches for the person running the slice authority?

I think this boils down to how each CF chooses to establish federation.
In our model, new SAs are accepted into the federation by the entity
running the federation, which everyone has agreed to trust.
I could imagine that other CFs might choose to have members of the
federation come up with pairwise agreements to accept each others' SAs,
to have a "root" SA that authorizes other SA, or to come up with even
more complex schemes.

> Do you expect that
> every slice gets reviewed by the person running the SA? Do you think
> there is a key management challenge given the numbers I mentioned above
> (1000's of researchers, 100's of aggregates)?

I expect that this is not specified by the architecture. The point of
the SA is to encapsulate this policy. In the PlanetLab model as it
stands today, yes, because the PI has to make the slice her/himself. In
the Emulab model as it stands today, no, because the project leader can
delegate creation rights to members of the project.

An entity trying to decide if it's going to trust an SA might use the
policy in use at the SA to decide whether or not to trust it. DETER
might decide to only trust SAs that have some kind of vetting process
for slices (like it does today for experiments), Emulab might be willing
to trust SAs with looser policies.

The main think I like about the SA abstraction is that it allows for a
large number of decisions about where to place SAs and what their
policies for issuing slice names can be.

> If a particular aggregate
> or federation has a policy that applies to, say, US persons.
> How might
> an SA-minted researcher identity include that as an authoritative attribute?

I see this as a separate statement - sounds like TIED is working on a
way to say things like this, and we've considered the idea that some
credentials may be simply assertions like this - there's some authority
that can hand out "is a US person" credentials, which the user could
present if talking to any entity that might behave differently for US
persons. (Of course, this only works for positive assertions, not
negative ones.)

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

Re: clearinghouses (or not)

2009-04-17T16:58:46Z

At 11:34 AM -0600 4/17/09, Robert P Ricci wrote:
> Similarly, in Emulab, every experiment is
>associated with a "project", so I know I can talk to the person who's
>registered as the head of the project that experiment is a part of if I
>have any issues with the experiment. The TIED project uses the same
>structure, as far as I know, as Emulab, since that's what it's built on.

well, just for the record, this is true today but in terms of access
control, etc, we're heading in the direction of a richer model based
on attribute logic. This is somewhat relevant because

a) various places in this discussion where people have written "we
delegate x to y" (say, "we delegate authorization to a
clearinghouse") are handled transparently - aka "just work" - within
the logic, and

b) it could potentially break the simple "talk to the head of the
project" model if you let it. But on the other hand it offers a much
more flexible version of "who the blazes said that was a good idea,
anyway?".

We -are- now getting close to some interesting policy issues of who
gets to know what, which I think have some room for growth in the
current story. but that's a bit beyond the technical question at hand
here.

john

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

Re: clearinghouses (or not)

2009-04-17T15:54:04Z

On Fri, Apr 17, 2009 at 10:31:53AM -0600, Robert P Ricci wrote:
> In my interpretation, an SA is a thing that has the ability to create
> new slice names. So, a user walks up to an SA, says "I want to create a
> slice", and that SA makes some policy decision about whether it's going
> to let them. If the SA decides to make a new slice name for the user, it
> bears some responsibility for what happens in that slice. An SA "vouches
> for" a slice by giving it a name.

Creating the slice/experiment as a first class object (with a name) is
one of the primary things fedd does on TIED as well. It does roll the
creation of the esperiment/slice in with the creation of the name, but
these are separable.

--
Ted Faber
http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG

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

attachment0 (202 bytes) Download Attachment

Re: clearinghouses (or not)

2009-04-17T13:07:24Z

> I don't quite understand this argument.

It actually sounds like you do understand my argument. Comments below.

> It seems to me there are three separate ideas tied up in the concept of a
> clearinghouse as most people are using the word:
>
> 1) decoupling - the ability to "disconnect" some functions from the AM and
> move them to somewhere else.
>
> 2) centralization - the provision of those functions for multiple AMs in a
> centralized manner, at one point in the system, rather than in a distributed
> way.
>
> 3) bundling - tying together several functions in one place.
>
> I agree that the "decoupling" idea is helpful to making composition or
> bundling of functions in different ways later on easier. But the assumptions
> about centralization and bundling that are also implied in the current
> definition seem to work in the opposite direction.
>
> I think what you're saying is that your vision of a clearinghouse is heavily
> centered on the decoupling goal, and not so much on the others - you argue
> that once functions are decoupled you can easily move them around, and
> although you don't mention debundling different functions into different
> places, perhaps you're considering it. But I'm not sure that this definition
> is completely consistent with how others are thinking about the word. Am I
> missing something?

Yes, if you get decoupling of functions right, then you can move
these functions around. As a result, you get the other two ideas you
mention for free (depending on how you shift functions to the
Clearinghouse and away from the AM/CM). To be clear, I see the merit
in all three of your ideas as it relates to a Clearinghouse's
functions.

However, when people have discussions about Clearinghouses, Slice
Authorities, Slice Managers, Aggregate/Component Managers, etc., they
seem to really be discussing how certain functions are divided up
between them. My view is that all divisions of functions are useful
and have value (depending on the tradeoffs you want to make and the
scenarios you want to support). I'd prefer not to preclude any
scenarios.

The goal should then be to decouple functions as much as possible, so
you can support different compositions of functions in the principals
at different times. In Orca, this assignment of function is fluid.
As one example, the system can organize itself such that AMs reserve
control of their resource/access policies, or it can organize itself
such that all AMs delegate to one or more trusted Clearinghouses. It
could also do one or the other at different periods of time.

-David

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

Re: clearinghouses (or not)

2009-04-17T12:38:34Z

Larry Peterson wrote:

> Comments inline...
>
> On Fri, Apr 17, 2009 at 9:51 AM, Aaron Falk <falk@...> wrote:
>> On Thu, Apr 16, 2009 at 6:25 PM, Aaron Falk <falk@...> wrote:
>>> Thank you Larry for starting an interesting thread. You and Rob have
>>> listed several candidate functions for Clearinghouses that don't really
>>> match the clearinghouse functions that Chip described at GEC4 (slide
>>> 15-21 of [1]). Those functions really revolve around accountability:
>>>
>>> 1. User log-in. A place for a user to create an account; it needs
>>> to be capable of validating there is an organization accountable for
>>> their actions. It's not clear whether this validation is included
>>> in the credential manager you mentioned.
>>>
>>> 2. Transaction Logging. A reliable record of all resources a user
>>> consumed. Needed to determine accountability if something bad
>>> happens.
>>>
>>> 3. An ability to enforce global policies.
>>>
>>
>> Larry-
>>
>> In your SFA doc, you define a slice authority to be a principal
>> "responsible for the behavior of a set of slices, vouching for the
>> researchers running experiments in each slice and taking appropriate
>> action should the slice misbehave." Would you agree that this is
>> roughly analogous to clearinghouse functions 1. and 2. as I've described
>> them?
>
> So what value-added does the clearinghouse provide? My point is that
> the SFA lays out a set of "functions". (We've since identified some new
> "sub-functions" because some people imagine building a widget with less
> functionality than the SFA prescribes, and so want to off-load the missing
> piece to someone else.) As I said before, a clearinghouse is a collection
> these functions -- you choose to bundle functions 1 and 2... the next guy
> chooses to bundle 1, 2, and 3. Bundling is fine, but it's an exercise in
> managing the implementation task (usually by simplifying it in some way).
> It's not prescribing anything architectural.

So, we're building prototypes, right? "Multiple, competing control
frameworks..." I think we should be give preference to trying to
understand what the requirements are and what designs can meet them.
IMO, GENI could easily include 100's of aggregates and 1000's of
researchers and I'm trying to understand various approaches to access
control, logging, and global policy is and whether they can accommodate
that kind of scale. For me, the clearinghouse has been helpful for
reasoning about what functions GENI requires and I have described three
functions that I think are needed. For each of the functions we can
argue that a) it isn't required, b) we don't need to worry about it now,
or c) there's a design that provides them. They are bundled in the
clearinghouse because, IMO, they are hard to distribute in a scalable
way and so are natural candidates for centralization. However, I'm not
wedded to centralizing them, especially if it can be shown that there
are robust approaches for distributed implementation. It would
particularly helpful to me if you could map SFA functions (or any other)
to them so I can understand how they are achieved.

>> Larry Peterson wrote:
>>> I don't think those are the right functions.
>>>
>>> 1) A place for a user to "log in" -- that's what we have
>>> registries for. You just need to get your university's
>>> authority (PI in PlanetLab-speak) to vouch for you.
>>> Then you acquire the credential(s) you need and
>>> you're off and running.
>> I don't think we should require every university to run a slice
>> authority to be able to participate in GENI. As the value of the
>> resources that can be acquired in GENI grows, the need for
>> accountability will grow. There will be policies for what it takes to
>> acquire a GENI log-in (who is vouching for the PI? what fidelity of
>> out-of-band ID verification is needed?). This will add to the burden of
>> running a slice authority.
>
> Yes, every university should have a slice authority -- I can't know
> whether to approve Joe Random Student's slice; only you do. That
> does not mean every university runs their own registry, which
> records trust relationships created by slice authorities. In our version,
> PLC runs a registry on behalf of all US universities and PLE runs a
> registry on behalf of all European universities. If one day MIT asks
> to run their own sub-registry, we ought to be able to support that, but
> we don't require it.

OK, this helps. The SFA says the slice authority is a principal. But
it's also software, right? How is an SA bootstrapped? I.e., who
vouches for the person running the slice authority? Do you expect that
every slice gets reviewed by the person running the SA? Do you think
there is a key management challenge given the numbers I mentioned above
(1000's of researchers, 100's of aggregates)? If a particular aggregate
or federation has a policy that applies to, say, US persons. How might
an SA-minted researcher identity include that as an authoritative attribute?

>>> 2) Transaction logging -- implies a global "red button".
>>> I don't think you have that feature in a truly
>>> federated world. At the end of the day, each
>>> aggregate has to protect itself.
>> I think transaction logging and 'red button' represent two functions,
>> although the latter depends on the former. Logging gives you a way to
>> figure out what happened after the fact. If there is an attack launched
>> from GENI resources (deliberate or inadvertent) we should be able to
>> figure out who was accountable for those resources at the time. Are
>> opposed to collecting any logs of resource utilization? If not, where
>> do you think they should be? Do you oppose having a single
>> "authoritative" log?
>
> There is an audit mechanism at the lowest level. It maps network
> activity to slice. It's then a matter of figuring out globally where a
> a bad slice exists. If we do not assume a single centralized slice
> manager -- which I think is the case -- then we do not have a "root"
> from which we can find all aggregates/components hosting that
> slice, so the burden falls to aggregates to watch out for their own
> interests.

That approach seems only to assume a) misbehavior is associated with
network activity (and there are other ways a slice can go out of control
- think wireless) and b) a packet includes sufficient addressing that it
is possible to map it to a slice (packet from lower-layers experiments
might not). Finally, it requires network reachability to consult the
mechanism and in the worst cases this might not be available. So, I see
this as a useful tool but not sufficient.

>
> This is a non-trivial discussion that we've had on various phone
> calls. It's difficult to summarize in this context, but in summary,
> unless we mandate a single GENI root/clearinghouse with a big
> red button, and I hope we don't because it negates the advantages
> of federation, then we have to develop other mechanisms by
> which bad slices are squashed.

Nevertheless, I think the question of what does one do about slices that
are out of control is important enough that it shouldn't be punted to
later. If a centralization approach is the only way to accomplish it,
we should at least prototype one to understand the tradeoffs.

>
>> W.r.t. the 'red button' function, again, as the value of GENI resources
>> grows, the damage that can be done will grow and the need to shutdown
>> slices will grow. I didn't think you were opposed to that. I'm not
>> suggesting that the mechanism needs to be centralized, just reliable.
>> (It seems to me that a transaction log would be useful for such
>> mechanisms but perhaps I'm wrong.) There's the open question of who can
>> request a slice to be shutdown and I don't think we have a sufficient
>> understanding of operations yet to say. If there is GENI-wide
>> 'meta-operations', it seems to me that they might become aware of slices
>> that need to be shutdown and should probably have that ability. While
>> it's still too early to say, I think we shouldn't design that out of the
>> system.
>
> I think there's likely some sort of inter-NOC, and humans are involved.
> I don't think I'm ever going to be willing to give you the credential
> to shut
> down a slice on my aggregate. Slices do go bad, but the more common
> scenario is that alarmists throw tantrums about slices without just cause.
>
>>> 3) Global allocation policy -- to the extent anything
>>> is global, then yes, you need something like this.
>>> It corresponds to one of the functions I named
>>> earlier (Resource Manager... I forget which number
>>> I gave it). But again, I think allocation rights originate
>>> with the owner of the aggregate; they may or may
>>> not delegate to a global entity.
>> I think we are in agreement then. I don't think we've wrapped our heads
>> around the implications of global policy yet but it does seem to me that
>> a consenting aggregate should be able to grant a researcher something
>> that is beyond the 'global' policy.
>
> I agree we don't understand this yet. I do think there are two different
> perspectives (starting points), though. One is based on the presumption
> of a global policy -- it focuses on how we achieve it. The other is based
> on the presumption of aggregate autonomy -- it focuses on mechanisms
> to support peering, should consenting aggregates have incentive to do
> so. I tend to come at this from the latter perspective.

Regardless of perspective, I am trying to learn whether your SFA is
capable of implementing a policies requiring some global knowledge.
Again, given that we are building prototypes now, it would be good to
understand what it would take to provide that capability.

--aaron

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

Re: clearinghouses (or not)

2009-04-17T12:37:06Z

At 11:08 PM -0400 4/16/09, David Irwin wrote:

>
>This is a point that underlies Orca's approach----we put nearly all of
>the discussed functionality (in some form) in our Clearinghouse
>because we can always have multiple Clearinghouses or combine AMs with
>their own Clearinghouse (so the AM takes on its functions) in
>different ways to effectively produce a different "bundle" of
>functions. Taking the opposite approach---by putting few functions in
>a Clearinghouse initially---may make composing/bundling these
>functions in different ways later on more difficult.
>
>-David

Hi David,

I don't quite understand this argument.

It seems to me there are three separate ideas tied up in the concept
of a clearinghouse as most people are using the word:

1) decoupling - the ability to "disconnect" some functions from the
AM and move them to somewhere else.

2) centralization - the provision of those functions for multiple AMs
in a centralized manner, at one point in the system, rather than in a
distributed way.

3) bundling - tying together several functions in one place.

I agree that the "decoupling" idea is helpful to making composition
or bundling of functions in different ways later on easier. But the
assumptions about centralization and bundling that are also implied
in the current definition seem to work in the opposite direction.

I think what you're saying is that your vision of a clearinghouse is
heavily centered on the decoupling goal, and not so much on the
others - you argue that once functions are decoupled you can easily
move them around, and although you don't mention debundling different
functions into different places, perhaps you're considering it. But
I'm not sure that this definition is completely consistent with how
others are thinking about the word. Am I missing something?

Thanks,
John

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

Re: clearinghouses (or not)

2009-04-17T11:08:19Z

Thus spake David Irwin on Fri, Apr 17, 2009 at 01:54:58PM -0400:

> > A slice-name is a global identifier. So, I'm not sure I quite follow
> > your comment about instituions having to establish relationships with
> > every user. If you have some resources I want to use, I approach you
> > with a valid slice name that has been signed by some SA. You look at my
> > request and decide if you want to give me anything, and you very well
> > might look at which SA my slice was created by in making that decision.
> > (In our implementation, every member of the federation is given a list
> > of trusted SAs by the clearinghouse, but this is clearly not the only
> > possible design/policy.)
>
> I was assuming that each Institution runs its own Slice Authority (as
> per Larry's last email in this thread). I was assuming that this
> Slice Authority only controlled slice names at that institution (and
> not at other institutions, since that would impinge on their own
> ability to control their local policies). Your comments indicate that
> any institutions SA could apply a policy for creating/naming slices
> that other SAs must (always) conform to.

I don't see this as an issue of policies between different SAs - no SA
is bound by the policy of any other SA. Each SA is creating slice names
independently. The place where the SA's policy might interact with
another entity's policy is with an AM/CM. If an AM knows something (or
doesn't know anything) about a particular SA's policy for slice
creation, it might decide not to give any resources, to give limited
resources, etc. to slices from that SA. (Of course, the AM could have
plenty of other inputs into its policy decision, such as the identity of
the user, etc.)

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

Re: clearinghouses (or not)

2009-04-17T11:01:53Z

> I think the overall point here is that SAs *could* be bundled with
> either CHs or AMs (in our implementation, we bundle them with AMs), but
> that it offers valuable flexibility for the architecture to not *require*
> that it be bundled with either one, since bundling with the CH implies
> more centralization that some of us are comfortable with, and bundling
> with the AM implies that accounts somehow go with resources, which is
> not necessarily desirable either.

I mostly agree here, with one caveat. I would say that a GENI control
framework architecture should *require* the flexibility to do both
(even in the same deployment at different principals at different
times).

-David

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

Re: clearinghouses (or not)

2009-04-17T10:57:04Z

Thus spake David Irwin on Fri, Apr 17, 2009 at 01:40:15PM -0400:

> > I see the SA as a pretty simple way to capture this set of schemes for
> > responsibility, which on one level are pretty similar (groups of users
> > for which some higher entity has claimed responsibility) and on another
> > level are pretty different (in PlanetLab, they must be organized by
> > institution, and in Emulab, they don't have to be, and the delegation
> > model for who is able to create slices differs), under a nice common
> > umbrella.
>
> Sure. The SA as you've defined it represents an important function.
> It Orca this important could either reside at a Clearinghouse or in
> each AM at different periods time.

Good, that it also fits ORCA would seem to indicate that the function of
the SA was designed well. :)

I think the overall point here is that SAs *could* be bundled with
either CHs or AMs (in our implementation, we bundle them with AMs), but
that it offers valuable flexibility for the architecture to not *require*
that it be bundled with either one, since bundling with the CH implies
more centralization that some of us are comfortable with, and bundling
with the AM implies that accounts somehow go with resources, which is
not necessarily desirable either.

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

Re: clearinghouses (or not)

2009-04-17T10:54:58Z

> Right - I see three separate statments to make here:
>
> 1) I vouch for the identity of this person
> Made by some authority (I'm not sure it has a name), by issuing a
> GENI identity to that person
> 2) I take responsiblity for the actions taken by this slice
> Made by a slice authority, by issuing a name for the slice
> 3) I allow this slice to use some resources
> Made by a component manager, broker, etc. depending on the model by
> issuing a ticket to that slice
>
> The authorities in #1 and #2 *could* be institutions, and in fact could
> be the same entity, but the model itself does not require that.

Sure. Even #3 could be an institution (operating its own broker, for
instance) for that matter. Or all three of these functions could be
inside of a Clearinghouse. Or they could be split between
principals.

> A slice-name is a global identifier. So, I'm not sure I quite follow
> your comment about instituions having to establish relationships with
> every user. If you have some resources I want to use, I approach you
> with a valid slice name that has been signed by some SA. You look at my
> request and decide if you want to give me anything, and you very well
> might look at which SA my slice was created by in making that decision.
> (In our implementation, every member of the federation is given a list
> of trusted SAs by the clearinghouse, but this is clearly not the only
> possible design/policy.)

I was assuming that each Institution runs its own Slice Authority (as
per Larry's last email in this thread). I was assuming that this
Slice Authority only controlled slice names at that institution (and
not at other institutions, since that would impinge on their own
ability to control their local policies). Your comments indicate that
any institutions SA could apply a policy for creating/naming slices
that other SAs must (always) conform to.

-David

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

Re: clearinghouses (or not)

2009-04-17T10:48:47Z

Thus spake David Irwin on Fri, Apr 17, 2009 at 01:35:00PM -0400:

> > I think it's distinct, becuase simply having a slice name does *not*
> > entitle you to any resources. There is still policy that goes on when
> > deciding whether or not to grant you tickets (and those policy decisions
> > could take which Slice Authority authorized the slice into account.) The
> > SA is claiming some level of responsibility over what happens in the
> > slice, whatever resources it turns out people are willing to give to the
> > slice.
>
> Fair enough. I see. In this case, the "policy" may not have anything
> to do with the resources.

Right - I see three separate statments to make here:

1) I vouch for the identity of this person
Made by some authority (I'm not sure it has a name), by issuing a
GENI identity to that person
2) I take responsiblity for the actions taken by this slice
Made by a slice authority, by issuing a name for the slice
3) I allow this slice to use some resources
Made by a component manager, broker, etc. depending on the model by
issuing a ticket to that slice

The authorities in #1 and #2 *could* be institutions, and in fact could
be the same entity, but the model itself does not require that.

> However, my point is still valid. There is
> no reason why this SA couldn't choose to delegate this responsibility
> to a Clearinghouse it trusts for some period of time. Doing that does
> provide some value, since each institution now doesn't have to
> establish a relationship with every User that wants to run on its
> resources. Its fine if an institution doesn't want to delegate so it
> can apply its own policies, but it should be able to do both.

A slice-name is a global identifier. So, I'm not sure I quite follow
your comment about instituions having to establish relationships with
every user. If you have some resources I want to use, I approach you
with a valid slice name that has been signed by some SA. You look at my
request and decide if you want to give me anything, and you very well
might look at which SA my slice was created by in making that decision.
(In our implementation, every member of the federation is given a list
of trusted SAs by the clearinghouse, but this is clearly not the only
possible design/policy.)

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

Re: clearinghouses (or not)

2009-04-17T10:40:15Z

Orca has a similar structure. Every slice is associated with a
principal that controls that slice. The principal could represent an
entire institution or an individual researcher (doesn't really
matter). The AM either knows who this principal is or can find out
(by talking to a Clearinghouse it trusts that approved this
principal).

> I see the SA as a pretty simple way to capture this set of schemes for
> responsibility, which on one level are pretty similar (groups of users
> for which some higher entity has claimed responsibility) and on another
> level are pretty different (in PlanetLab, they must be organized by
> institution, and in Emulab, they don't have to be, and the delegation
> model for who is able to create slices differs), under a nice common
> umbrella.

Sure. The SA as you've defined it represents an important function.
It Orca this important could either reside at a Clearinghouse or in
each AM at different periods time.

-David

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