Re: Work Group Last Call: Desired Enhancements to GSSAPI Naming

Jeffrey Altman wrote:
> 
> I am happy to announce the start of a two week working group last call
> for the Kitten work item "Desired Enhancements to GSSAPI Naming".
> http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-03.txt

Sorry for not having read and commented on this draft earlier.

I have a different perception about gssapi naming issues
than what is described in this document.  You expected that, didn't you  :)

General comments:

First of all, I'd like the issue of authorization (which includes
group memberships, attributes, etc.) to remain entirely seperate from
authentication in GSS-API.  

Where authorization is desired (be it in a pseudo-generic fashion
or as proprietary as gssapi mechanism implement it today), it should
be done through an entirely seperate set of API calls and not
be hacked into the existing naming API.

Any kind of hacking up / overloading the naming API is likely to break
existing applications.  In order to make use of new extensions/concepts,
the application will have to be changed anyway -- so we better use
a seperate and clean API calls for that purpose instead of making
contortions to the existing API.  With seperate API calls, it
will be much easier for the application to distinguish whether
and which additional attributes, group memberships, etc. are
available, the application will not have to frob existing API calls
in new ways and try to make sense of the results.

Comments on specific sections:

Section 2. Kerberos Naming 

The existing scheme of binary canonical names for ACLs is perfect.
No gssapi (v2) mechanism should ever be allowed to fail gss_export_name()
for a mechanism name (MN).

Implementing an Enterprise Name could be done in a straightforward
and fully GSS-API v2 compliant fashion!

Remember that ACLs may be large (could be more than a million entries;
we have around 40000 entries on some of our systems and we already have
customers with 200000 entries), so an ACL lookup that would not only
require a linear search, but also costly transformations on each entry
would be prohibitively expensive.

I consider an Enterprise Name an extension of the Kerberos protocol,
so the necessary provisions to make it work transparently for
GSS-API v2 apps is with the Kerberos GSS-API mechanism.

If Enterprise Names are implemented in a way that they entirely replace
the original Kerberos principal names at the GSS-API level, then
the existing model would work just fine.  In the representation of
the exported names, they should receive a different OID in the generic
framing than traditional Kerberos principal names, but I don't see
a problem with that (there, the wording of GSS-API v2 would only need
a slight adjustment, but no actual change).   Of course, Kerberos must
be able to distinguish Enterprise Names them from traditional Kerberos
Principal names for the purpose of ACL maintenance (printable to exported
binary conversion), but that should be fine.  *I* wouldn't mind if
that meant a new nametype -- this is why the nametypes parameter
exists in gss_import_name().

At the Kerberos protocol level, the Enterprise name should become
part of the ticket -- it could accompany or replace the existing
Kerberos principal name (that's up to the Kerberos protocol wranglers
to decide), potentially with an indicator supplied by the KDC which
name is to be the default if both names are included in the ticket,
and then an (updated) Kerberos GSS-API mechanism would export
the enterprise name through gss_export_name() instead of the Kerberos
principal name.

There really is no need to make things any more complicated
at the GSS-API level and for GSS-API portable applications.

While you're at it: It might be a good idea to make those enterprise
names case-insensitive and force them all lowercase on output --
several bugs in Microsoft's software (API,UI,wire protocol) are a royal PITA
in combination with the case-sensitivity of the Kerberos principal
names in the standardized Kerberos protocol (which can not be avoided
in heterogeneous environments with non-Microsoft Kerberos implementations).

Section 3. X.509 Names

There are plenty of reasons why particular certificates may not be
usable with a particular SPKM-like gssapi mechanism, not just
"it has an empty DName".  Many CAs issue certificates with strict
limits on their usability in order to defend their business model...

The decision which subjectAltName extension should be used might
be difficult to decide.
  * should there be a seperate subjectAltName extension for every application?
    - this would require a registry for apps to preven collisions/ambiguity
    - this would grow the size of certificates with every new app
    - it would require a new or different certificate for every new app
or should there rather be a list of subjectAltNames and each application
should search for best fit (or leave the mechanism default if the app
doesn't recognize any)?

It also depends of the capabilities or willingness of the CA to issue
specially tailored certs.  I assume that sysadmins/customers today
would like to start with subjectAltNames encoded into a RDN component
today (because that is what their current CA software would allow them
to do), and eventually switch to using a real subjectAltName extension
whenever the software supports that switch (preferable: a migration).
That will, of course, require the necessary hooks (hacks) in the
gssapi mechanism implementation. :)

One possibility would be to add one new gssapi call
  gss_set_nametypes_preference(gss_OID mech, gss_OID_set nametypes )
where the application can tell the gssapi mechanism which nametype(s)
should be used when gss_display_name() is called and when gss_export_name()
is called.  The gssapi mechanism needs to be configurable by the
sysadmin for the list of attributes that are going to be present
in certificates (and a fallback identifier or fallback preference
list if the attribute is not present).  From that admin-configured
list, the gssapi mechanism will should use those nametype(s) which
it implements for the output of gss_display_name()
and gss_export_name(), and show that to the application when it calls
gss_inquire_names_for_mech().

The application should be permitted to "blindly" provide a preference
list through its preference call (above) and have the mechanism ignore
unrecognized nametypes (resulting in default behaviour if either
no nametype is recognized or the parameter did not contain a nametype).

With a call like gss_set_nametype_preferences(), we could additionally
solve the character set issue that currently exists in GSS-API v2:
by defining a Pseudo-nametype OID "GSS_C_NT_USE_UTF8_PRINTABLES"
we could provide a mechanism-independent forward migration path
for the encoding of the printable output of gss_display_name().
If the supplied mech_oid is GSS_C_NULL_OID, then the preference
list should equally apply to all mechanisms of a multi-mechanism.

(I admit that support for GSS_C_NULL_OID might difficult for a
 layered multi-mechanism where some mechs support the optional
 gss_set_nametype_preferences() and some don't)

No matter what we define or implement, the sysadmins will have to
change all of their ACLs at least one more time if they want to
make any use of those features.

And one should also not forget that quite a number of sysadmins
and managers see it as a feature that they effectively revoke
access rights by issuing new credentials to a user that moves
to a different department or (sub)division within a company,
and I can see as many advantages as there are inconveniences.

If the ACLs do *NOT* distinguish between "access granted based
on identity" and "access granted based on role/authority/membership"
then it will be impossible to come up with a silver bullet to the
user rename/relocate within organization problem.

But no matter that whatever we define today, I'm convinced that
we can not protect sysadmins and end users from going through
ACLs troubles because of new credentials tomorrow.  There
will be continuous invention of new naming scheme and
authorization models, just as there have been in the past.

4. Composite Name , Name Attibutes

There is an extremely high lock-in potential in authorization information
besides the authentication itself, no matter whether one looks at
X.509v3 certificate extensions, contents of a Microsoft PAC or a
DCE privilege certificate or something along those lines.

Once you start depending on those attributes in your application,
you may no longer be able to support gssapi mechanisms or
authentication schemes that do not provide this information.
This SIGNIFICANTLY reduces the portability of the application.

The other significant issue with this is that all existing schemes
do not scale well, and the way they work this isn't going to change.
There is a fairly low limit on the number of group memberships on
Microsoft Windows, and in the current architecture, the attributes
always travel the wire during authentication.  This creates a bandwidth
issue and it also means that fine-grained authorization (with 1000+
capabilities/authorizations) may be entirely impossible with
certain applications.

A lot of security architectures assume that everything can be
mapped to a filesystem with ACLs on files.  Once you learn how
business process work, you have to realize that this perception
is extremely flawed, and Posix-style ACLs are a dead-end road
for some types of applications.

It's fine if GSS-API is used for access control to, what essentially are
"network file services" -- be it a NFS-, CIFS-, FTP- or simple HTTP-server.
But there are other services that need GSS-API services and which do
not fit the "one size fits all" everything-is-a-file access control model.

And even the "file server" model is several magnitudes more difficult with
Microsoft's Access control model than with the traditional Unix access
control based on User/Group/Other permissions.

In the Unix world it has been fairly simply to apply appropriate access
control to files, and a lot of software has been applying access control
on Unix.  On Microsoft Windows, however, access control has been notoriously
difficult and it took Microsoft 10 years to learn how to implement it
(one of the reasons for the many backwards incompatible NTFS revs)
and how to use it.  Trying to apply an ACL for private use to a file
in software where a single binary runs on all Win32 plattforms
(nt3.5+,win95+), and correctly dealing with network shares that are
connected with non-default credentials is neither easy nor straightforward...

The use of GSS-API based authorization information is something that
can only be used by entirely new designed applications once the necessary
apis and gssapi mechanisms and authorization infrastructure&configuration
is available -- very few, if any, legacy application will use it (and I
do mean "legacy application" here, not simple network file services).

If you look at the GSS-API spec, it was invented with legacy applications
in mind, which is why it has a clear focus on authentication and
proctection of the communication, and doesn't touch the details
of authorization (in the base spec).

4.3 Handling of gss_export_name

An authentication mechanism for which gss_export_name can not meaningfully
be defined is so seriously broken that it should not be
considered a GSS-API mechanism, i.e. if a mechanism can not be used
by a portable gssapi-based application that requires name-based
authentication, then this mechanism is not generic enough to deserve
the term "Genenric Security Service".

There's no problem if a mechanism provides additional features (which
portable apps do not care about), but there is a real problem if
there is less than the base GSS-API v2 spec.

7. Selection of Source Identity

This interpretation in the document is somewhat too strict:

   Currently GSS-API credentials represent a single mechanism name. that
   is, by the time credentials are acquired, a particular single
   identity must be chosen for each mechanism in the credential.  All
   these identities must correspond to a single mechanism independent
   name.

Traditionally, GSS-API initiators are recommended not to worry about
the name tags on their credentials.  Instead, they were suggested
to call gss_init_sec_context() with GSS_C_NO_CREDENTIAL, which
would cause the mechanism to select the default credential
(or maybe the most appropriate credential for the given target).
If you check rfc1508, gssapi v1 mechanisms were allowed to entirely fail
gss_acquire_cred() for initiator or both credentials, or to fail it for
anything other than a NULL name (called GSS_C_NO_NAME in v2).

If the initiator passes GSS_C_NO_NAME into gss_acquire_cred()
along with a set of OIDs, the mechanism is permitted to delay
the selection of an actual credential until this handle is passed
into gss_init_sec_context(), (or when it is passed to
gss_inquire_cred() or gss_inquire_cred_by_mech() with an output
handle for the name or when the credentials have individual lifetimes.)
Only those characteristics of GSS-API objects (contexts,credentials)
that are revealed to the application caller must be nailed down once
they're revealed, unrevealed characteristics may delay their resolution
until a GSS-API call needs them to take a particular fixed value.
A call to gss_init_sec_context() and gss_accept_sec_context()
which returns GSS_S_COMPLETE will have to nail down the particular
name in an explicitly supplied credential for the suceeding mechanism,
as does gss_inquire_cred_by_mech() or gss_inquire_cred() for the default
mechanism. 

Delaying the local selection of a credential/identity based on the target
name passed into gss_init_sec_context() is therefore *NOT* generally
precluded in the existing GSS-API v2.

For a mechanism where identity and privileges are not cleanly
seperated, it might be useful to delay the selection of the
a specific default credential until gss_init_sec_context() is called,
wherever/whenever possible.

The preferable solution would be that gssapi mechanisms cleanly
seperate identities from privileges/authorization information,
so that the identity selection can happen during gss_acquire_cred()
and the creation of tailored/target-specific privilege attributes is
performed during gss_init_sec_context() in a seperate step, when
the communication peer is specified.

Addition of a new API call like gss_acquire_cred_for_target()
might be easier to deal with by a gssapi mechanism, but
it would be preferable if the necessary magic happens already
within the existing GSS-API v2 calls because that is what
the existing GSS-API-based apps are calling.

-Martin

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten