« Return to Thread: What are GIDs good for?
Re: What are GIDs good for?
by Robert P Ricci
::
Rate this Message:
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
>
> 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
« Return to Thread: What are GIDs good for?
| Free embeddable forum powered by Nabble | Forum Help |
