|
What are GIDs good for?
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: What are GIDs good for?
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
|
|
Re: What are GIDs good for?
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?
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
|
|
Re: What are GIDs good for?
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
|
|
Fwd: What are GIDs good for?
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?
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
|
|
Re: What are GIDs good for?
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
|
|
Re: What are GIDs good for?
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?
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?
The URN proposal and details can be found at:
http://gmoc.grnoc.iu.edu/https/globalnoc/gmoc/file-bin/urn-proposal2.pdfIn 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?
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
|
|
Re: What are GIDs good for?
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?
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) 