[Handle-globus] Airplane rambings: URIs, handle owners, naming conventions map to policy...

[Frank Siebenlist <franks@mcs.anl.gov>]

UrisAreTheWay

We need a consistent way to name things, to map other naming schemes
into, and we need a conventions that translate to common semantics.

The proposal is to use URIs as much as possible. It has a well defined
naming scheme with simple rules for comparison. Furthermore, it maps
relatively well to the use of XML.

Note that a handle can also be represented as URI, by using a schema
prefix of "hdl:", plus some other formatting rules to ensure that the
proper URI format is used
(??? - the URI naming seems somewhat more strict than the handle scheme
- what are the precise limitation? what is the mapping for handle=>hdl:
??? )


UriBindingsOwner

The general goal: every subject should be able to state what attributes
it binds to a resource.

As a consequence, every relying party should care about the issuer of
the resource attribute bindings.

Although the handle system does provide security features, it does not
change the general premise that consumers of the handle values should
care about the "minter" or "owner" or admin of the associated name binding.

First of all, we have the HS root service, which is identified by a
public key. All HS clients and servers are pre-configured with that
public key: it is the HS trust-root, and all trust is derived from that.
Furthermore, we assume that the HS root server deployment is in the good
hands of CNRI: we can trust the integrity of the binding information
when it is authenticated by the HS root PK.

The subject associated with the NA-svc is the NA's identity, which
essentially is associated with the public key used in the native handle
protocol to authenticate that NA. This PK is maintained by the HS root
server.
We should be able to trust the binding between NA and public key as it
is maintained by the HS root service. This implies that we should only
trust communication about binding information maintained by an NA if it
is authenticated with the PK that is bound to that NA by the root service.

That, however, is only part of the story...

The integrity of the binding information depends on the NA's server
deployment. It should be clear that there is a difference in the "trust"
we have in binding integrity between a server  deployed in a
professional data-center or one that runs on a Windoze-98 PC connected
to the whole Internet. So even if the binding between NA and the NA's PK
can be trusted, the binding information as maintained by that NA is a
different matter.
Let us assume for now that the NAs that we care about are deployed in a
professional data-center, like NCSA, ESnet, SDSC, CNRI, MCS-ANL, etc.,
such that we don't have to worry about the integrity of the name bindings.

That, however, is still only part of the story...

All handle-value bindings are maintained by handle-administrators (HAs).
Each NA-server has at least one and potentially many (and I mean MANY)
administrators. There is a complicated access control policy that is
enforced in the handle server, such that only some HAs can create new
handles, some can add other HAs, some HS can only add bindings, some can
only change, some can only read...

This implies that consumers of handle binding information also have to
"trust" the enforced policy by certain NA servers, and note that that
policy can be different for each NA.

Having possibly arbitrary handle-value policy for each NA and possibly
every handle underneath an NA is too complicated for warm-bodies to
understand and to deal with: we need to use policy conventions that
should be properties of an NA.
In that way, you would give a relying party a way to "understand" how a
certain NA is managed, and what the trust assumptions are for certain
name bindings.

The most simple policy convention is one where one implicitly trusts all
the possible NA's admins for all the name bindings one cares about. In
other words, we simply trust whatever binding info we get back without
being concerned who administered the bindings as long as the NA vouches
for the binding through its PK.

Note that this doesn't imply that we have to trust the NA for all
possible bindings, but only for those we care about.
For example, we could decide only to ask a certain NA for bindings for
handles that match the pre-fix: "12.34/subject:", and only the bindings
for the single handle-type "uri:....eduAffiliate".

If we go one level more complicated by caring about the admins for
certain handles, it makes sense to consider some additional conventions
that makes it possible to deduce from the handle-name itself who the
owner is.

The native access mechanism in the HS does not seem to allow for
fine-grained policies where one can assign different HS-admins with
different rights for different handle-values for the same handle and
same handle-value-type.
For example, for a single handle of
"12.34/resource=uri:url:http://acme.com/transfer-svc";, and a single
handle-value-type of "uri:resource-owner-x509name", we care about the
particular HS-admin who binds the identifying subject's DN to a
particular resource. In other words, we want to know who the HS-admins
are with change-permission for that particular binding. There could
potentially be more than one bindings for that same handle and
handle-value-type with different handle-values and where each of those
handle-values has different HS-admins associated with it. The expression
of this fine grained policy is not possible within the handle system:
realistically, the policy is normally on the level of the handles and
"somewhat" on the handle-value level.
(CHECK THIS WITH SAM AND LARS!!!)

An alternative way to achieve the ability to distinguish owner-specific
handle-values is by making the handle names themselves owner-specific
through a naming convention, and use top-level handle administrators to
enforce that policy convention.

One implementation option could use a convention where a prefix of
"12.34/owner=uri:....#" would denote the prefix of a name space that
that subject can manage as an owner.
For example, a handle of
"12.34/owner=uri:ldap:///cn=john%20doe,co=acme.com#resource=uri:url:http://acme.com/transfer-svc";
would allow mr. "john doe" to administer the bindings for the
transfer-svc like its associated x509 creds info.
Furthermore, it would allow a relying party that cares about both the
creds info of a certain service and who cares about the issuer of that
information, to construct the complete handle name that according to
that NA's policy convention, is managed by the issuer.

For this scheme to work, the policy convention has to be enforced by an
special admin-tool that runs as a higher-level HAs. This tool will
receive a request from "john doe" to create a new handle while this
principal has no privilege to create new handles. The handle creation
request will check whether this requested new handle is under john's own
name space prefix; if so, a new handle will be created, and john will be
made a HA that is allowed to admin new handles-values for that handle
(for that handle only, that is!).
After that handle creation, the normal handle admin tools and normal
handle policy enforcement can be used to allow john to manage its own
handle and associated handle-values.

This policy makes use of the notion of a subnamespace that can be
distinguished in the handle-names.

Again, the advantage of using a prefix that includes the handle-owner's
secure-name is that consumers of handle-bindings can construct those
handle-names.

A "secure-name" is a name that can be validated by the handle-creation
tool without the need for any additional trusted third party. That is
none in addition to those trusted 3rd parties used for the
authentication, like CAs, KDCs, domain controllers, OTP-servers, etc.
(note that the latter 3rd parties have to be trusted anyway if the
authentication identity binding of the associated secure-name is to be
trusted).
In other words, if you trust the authentication mechanism, then you can
trust that no one else can manage the same owner-specific name-space.
(at least initially as the owner may add other HS-admins to manage the
handles he/she owns...but you should probably trust the owner to do that
anyway...).


Multiple different identity creds for the same identity

If the same warm-body has both kerberos and x509 creds to authenticate,
then you would like the owner to be able to manage its handles
through whatever authentication mechanism (s)he choose to authenticate
(forget authentication strength policies for now...).
This would force the owner to add all her possible other secure-names as
HAs to all the handles it manages and creates, which can be a burden and
error-prone.

One other option would be to use one extra level of indirection: ask the
top-level admin to assign one subnamespace that can be managed by a
group of identities, and let the owner always request and manage handles
only within that subnamespace.
The handle-creation tool could manage a subject-group that would be
associated with a certain subnamespace such that any subject within that
group would be allowed to create new handles within that subnamespace,
and that group would by default be added as the HA of those newly
created handles. In that way, one owner could authenticate through
different means, and still be able to create handles and manage
handle-values.


TinyUriSvc

Need a tiny-uri service to obtain short URIs that warm-bodies can
reasonably easy type-in without the chance of error, maybe even
remember... and it should fit on a single line in an email message
without wrapping to the next line !!!




-- 
Frank Siebenlist franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory

_______________________________________________
Handle-globus mailing list
Handle-globus@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-globus