[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Here is my rambings on your earlier rambinging while getting trapped in the
airplane...

----- Original Message ----- From: "Frank Siebenlist" <franks@mcs.anl.gov>
To: <handle-globus@cnri.reston.va.us>
Sent: Sunday, June 26, 2005 11:21 PM
Subject: [Handle-globus] Airplane rambings: URIs, handle owners, naming
conventions map to policy...


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:
??? )


Yes. The URI naming is more restrictive than handle naming in a couple of
ways:

1) It defines a larger set of restricted/reserved characters so that URIs
can be separated from surrounding text (in html/xml documents).

2) It contains ASCII encoded characters only. Non ASCII characters has to be
converted to UTF-8 encoding first, and then hex-encoded in the form of %HH.

3) It has a pre-defined structure in terms of
     <uri-scheme> : [//] <uri-scheme-specific-text> [ ? <query> ]
                                  [ # <fragment> ]

To map URIs directly into "hdl:", we will need to use the exact set of
reserved/restricted character set as URI does. On the other hand, I think we
should allow non-ASCII characters to be used as long as the encoding is
specified. This is because URI encoding rule in countries not using ASCII
is a broken practice. Since we are defining a new naming scheme, we may
as well take care of the issue.

So my suggestion is to define the "gns:" namespace (grid-namespace) as:

  <gns>  ::= [ <encoding> @ ] <encoding-specific-portion>
  <encoding> ::= "uri" | "utf-8" | "IBM-852" | "MacCE" | "ISO-8859-2" | ...

Further, we can make less restrictions on the restricted/reserved character
set. For example, we may only need to restrict following characters to
allow separation of <gns> surrounding text: SPACE, '<', '>'. And we
may reserver character '@' to separate the <encoding> from the rest
of the identifier.

Restricted characters are characters that should not appear anywhere in the
identifier.

Reserved characters are characters that carry special meaning in identifier
syntax. If the identifier itself has to use such character, it must be escape
encoding in terms of %HH sequence where each
%HH is the hex value of each byte that's part of the character encoding.

Additionally, each <encoding> itself may introduce specific rules on how to
encode its <encoding-specific-portion>. For example,
uri@<uri-specific-portion> will have the
<uri-specific-portion> encoded according to URI syntax as defined in
RFC2396.


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.


Note also that we can associate certified attributes to each NA (in terms of
handle values bind to the NA handle) that are assigned to each data center.
A certified attribute may be issued to the data-center by some trusted
third-party for various QoS purposes, including authenticity, service integrity,
etc.

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.


I agree with you. I think there are two aspects of your suggestion:

1) We can define a policy framework to allow policies assigned to each
NA. The policies will dictate/describe how handle administration is
managed by the handle server hosting the NA.

2) The default handle administration model is used for handle administration
using handle protocol. Name-attribute-binding applications that uses the
handle system can very well define their own administration model. Further,
each namespace (identified by its NA) can have such administrative model
defined in terms of handle attributes assigned to the NA handle.
Applications can find the administrative model for each
namespace by querying the NA handle for such attributes.

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!!!)


This is true in terms of native handle administration. But again,
applications can define more fine-grained administration model by
establishing their own administrative data model. Such model can hide
the use of handle index with some designated application data type.


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.


The handle protocol and admin tool already supports this feature. That
is, a group-handle can be created to contain a list of other handles
(hence the redirection). Each handle in the group-handle is a member
of the group. When the group-handle is used as a HA of some other
handle, the handle-server will allow any member of the group-handle
to perform the administrative operation on that handle.


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


I should be simple to establish such service. But we will need to think
of what features we need to implement for the mapping algorithm
between URI to shortURI or URI to shortHandle.

I suppose we can implement it easily by maintaining the mapping
between URI and shortURI in some database. But some decision
needs to be made on the mapping algorithm.

If we care about the speed of lookup from URI to shortURI, we
probably want to do the mapping based on some hash algorithm.
Each shortened URI can be formed as:

<prefix>/hash-code

If we care more about easy to type or even remember, we can probably
just maintain a counter and add the counter by one each time a new URI
is registered. Each shortened URI can be formed as:

<prefix>/yyyy-mm-dd-AAA-###

where each A can be an alphabet between 'A' - 'Z' and each # is '0' - '9'.

Any thoughts/suggestions?


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