Subject: Comments on draft-hartman-gss-naming

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Oct 2004 15:50:57 -0500

- Section 1 (intro)

   See my comments today about mechs that lack a single canonical name.
   Namely, I don't agree that this is a real problem.

   I do believe that there are problems to be solved in this space,
   namely:

    - Some mechanisms, e.g., Kerberos V, do not map well onto the
      GSS-API's name canonicalization model, as you describe in section
      2.

    - How to get away from name-based access control?

      The referential integrity problem of how to keep name-based ACLs
      up to date as names are changed, deleted, re-used, is real and
      must be addressed.  The simplest way is to use internal
      identifiers, such as POSIX UIDs and GIDs and Windows SIDs, instead
      of names, in ACLs.

      The good news is that your name attribute proposal is part of the
      solution, in my view.

      I think this problem should be front and center, as well as:

    - How to access Kerberos V ticket/authenticator authorization-data
      and x.509 certificate extensions (and SPKM authorization-data)?

      Similarly, IMO your name attribute proposal is part of the
      solution.

   The name selection problem for mechs whose credentials may respond to
   multiple names is, IMO, partly a mechanism-specific problem (in that
   the mechs' context tokens had better assert one or another such name;
   if SPKM doesn't, well, that'd be bad news...), and partly an
   implementation-specific problem (in that the implementation should
   somehow select a name for use as the name of the credential that
   corresponds to GSS_C_NO_CREDENTIAL; the mechs' specifications can
   help here too).

 - Section 2 (Kerberos Naming)

   I agree, the Kerberos mechanism does not allow for reliable
   canonicalization of query names without access to credentials
   suitable for the purpose.  This is a serious problem for applications
   that utilize name-based authorization.  This calls for a
   GSS_Canonicalize_name() extension that takes a credential handle as
   an input, though that is no panacea, as the rest of your text makes
   clear.  Ultimately only MNs output by GSS_Inquire_sec_context() may
   useful for name-based authorization, and only as long as one is aware
   of the resulting referential integrity problem with using names,
   rather than UIDs/GIDs/SIDs/... for authorization.

   The other items in this section, in the 3rd and 4th paragraphs are
   generic though.

 - Section 3 (x.509 Names)

   See above.

 - Section 4.1, 1st paragraph

   Not only acceptors, but initiators also.

 - Section 4.1, 2nd paragraph

   Not only mechanism-specific, but platform-specific also.  I.e.,
   "internal" IDs like POSIX UIDs/GIDs and Windows SIDs are specific to
   platforms, not mechanisms.

 - Section 4.3

   IMO, most of the name attributes that folks will be interested in
   have generic representations or can be treated generically or,
   failing that, in platform-specific ways.

   Mechanisms's context tokens should not assert name attributes that
   cannot be validated nor should peers accept such assertions without
   validating them.  Because the assertions may be tied to the
   credentials, rather than the contexts (this is the distinction
   between authorization-data in Kerberos Tickets and Authenticators)
   name attributes need not always be asserted explicitly.

   Thus, w.r.t. your name attribute source tagging proposal I see two
   such sources: the credential, and the peer; for the latter there's
   really only two sub-variants: unvalidated, and validated -- how is
   probably not important to GSS applications.

   Finally, composite names (names w/ attributes) need an exported form
   for transfer between processes.  This is different from, and should
   not be confounded with the exported name form in the GSS-APIv2.

 - Section 4.3

   It would be nice to have a GSS_Inquire_name() API which is a superset
   of GSS_Display_name() and which includes information such as:

    - whether the name is an MN and, if so, the mech's OID
    - the source of the name (an established context, an exported name
      re-imported, a canonicalized query name, just a query name)
    - where applicable, the name type OID used to import the name

 - Section 5

   Note that if a credential is acquired for a composite name then the
   credential may also "carry" the given name's attributes.  The
   semantics here need to be specified: must the credential carry all
   such name attributes, where applicable? or may it carry some or even
   none?  Is an extended GSS_Acquire/Add_cred() API necessary?

 - Section 6

   I see this as applicable primarily to machine UID/GID and similar
   names for which concrete mechs may not have MNs.

Thanks,

Nico
-- 

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 20:38:05 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas>  - Section 1 (intro) See my comments today about mechs
    Nicolas> that lack a single canonical name.  Namely, I don't agree
    Nicolas> that this is a real problem.

I think your comments are only sufficient to convince me that we can
solve the problem, not that it doesn't exist.

In all the cases you discussed today, we're significantly changing
semantics from what GSSAPI v2 expects.  

I agree that we will in almost all cases end up with solutions where
gss_export_name does something.  I suspect in many cases that will not
be a good enough something that a GSSAPI V2 application will work
well; they wll often limp along.

You seem to be more willing to accept platform or
implementation-specific solutions to the canonical name problem than I
am.  Actually I'm not sure that I'm unwilling to accept these
solutions, but I'm sure we need to explore the problem space more
thoroughly before doing so.

In summary, I'm working towards a broad description of what we are
considering with naming.  I want to have a single document that
captures the goals we are trying to meet and the solutions we propose
to meet those goals.  If you end up believing that one of the goals
ends up being a non-goal, that's probably OK.  When we get to the end
and ask ourselves whether we've met our goals, you can argue that the
weight of things you believe to be non-goals in the evaluation should
be very low.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 Oct 2004 10:17:06 -0500

> semantics from what GSSAPI v2 expects.  

One semantic problem in the GSS-APIv2 that is related to this is the
fact that the Kerberos V mechanism requires credentials in order to
canonicalize names, and another is that a mechanism might not be able to
produce useful MNs except for established security contexts.

Ok, you convince me that there is a problem, but then I still see it as
separate from, though perhaps related to, the name-based authorization
problem; I think both should be given top billing in the abstract and
introduction :)

> well; they wll often limp along.

Indeed.  The reason I insist on exported name tokens for names like
machine UID which may not be MNs is so that existing ACL facilicities
can be adapted with minimal ACL format change, but the apps will
definitely require v3 features to take advantage of this (since v2
provides no way to discover the machine UID names associated with a
given MN).

> thoroughly before doing so.

Yes, but those solutions are just for the single canonical name problem,
not for the 

> weight of things you believe to be non-goals in the evaluation should

I'd like to start seeing some concrete interface proposals.  I think
some aspects of the GSS naming problems and some aspects of the
solutions we're working towards have received enough thought that it
would be helpful to see what interfaces might result; if nothing else it
would help me.  I can volunteer to produce some interface designs if you
wish.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 Oct 2004 12:09:36 -0400

>> In summary, I'm working towards a broad description of what we
    >> are considering with naming.  I want to have a single document
    >> that captures the goals we are trying to meet and the solutions
    >> we propose to meet those goals.  If you end up believing that
    >> one of the goals ends up being a non-goal, that's probably OK.
    >> When we get to the end and ask ourselves whether we've met our
    >> goals, you can argue that the weight of things you believe to
    >> be non-goals in the evaluation should be very low.

    Nicolas> I'd like to start seeing some concrete interface
    Nicolas> proposals.  I think some aspects of the GSS naming
    Nicolas> problems and some aspects of the solutions we're working
    Nicolas> towards have received enough thought that it would be
    Nicolas> helpful to see what interfaces might result; if nothing
    Nicolas> else it would help me.  

I completely agree that we're at a point where we could do this work
and that it would be quite beneficial.

I also think what I'm trying to do is reasonably beneficial.  My goal
is to have a document we can last call shortly after DC and publish as
informational that describes what we're doing and limits scope of
possible solutions.  Does this seem worth doing?

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 Oct 2004 11:22:58 -0500

> possible solutions.  Does this seem worth doing?

Oh yes, much like my guide to the v3 work, this sort of document can be
quite useful apart from actual, concrete proposals.

Nico
--