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

From: Sam Hartman <[email-masked]>
Date: Mon, 19 Dec 2005 16:23:53 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

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

Understood.  It would have been great to get your comments sooner but
I'm glad that we have them now.

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

Yes, although I'm not actually sure our perceptions are all that
different when we get down to what we're actually trying to
accomplish.

One thing I'll say up front is that it sounds like I didn't make it
clear enough that this document is about GSS V3 extensions.  I'm not
talking about changing GSS V2 behavior.

    Martin> General comments:

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

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

We considered that approach.  However you have to tie it together with
the rest of GSS-API somehow in order to take advantage of it in a
pseudo-generic manner.
Nico and I found two possible ties.

The first is to tie it in both at the credential level and at the
context level.  You would need to tie it in both places because for
asking question about credentials before you have a context, you need
it tied into the credential mechanism.  You want it tied into contexts
so acceptors can ask questions about authorization.

The other alternative is to tie it into names.

The working group has already adopted a work item that presumes this
will be tied into names rather than done another way.  This work item
was presented in Paris and featured prominently in the minutes.

I'd argue that there is a moderate barrier to revisiting the
fundamental approach we're considering here, but it is not impossible to
do.

I do prefer to bind things into the name.  I think that's a fairly
natural extension of what the GSS name construct means.  The name
becomes all the authenticated assertions that are being made by the
mechanism or that are carried by the mechanism.

I think that's consistent with thinking going on in other areas that
have considered naming.

I also believe that the benefits of having one set of APIs rather than
two ties both to extensions and credentials are important.

    Martin> Any kind of hacking up / overloading the naming API is
    Martin> likely to break existing applications.  

Keeping existing applications working with existing mechanisms is an
absolute requirement of this work.  Keeping existing applications
working with new mechanisms that provide GSSAPI V2 functionality is
also an absolute requirement.  If we allow GSS V3 mechanisms that
would not be valid GSS V2 mechanisms, then I don't think we can
guarantee that existing applications would work with those mechanisms.
I think that's the only way in which we should break compatibility and
I believe we need to have a discussion to make sure that an existing
application does not accidentally get a GSS V3 mechanism that is
missing features for GSS V2

It's certainly been the intent of my draft that if you use the
existing naming APIs you get behavior that will not break existing
applications.  Would it address some of your concerns if I added a
section on backward compatibility requirements?

    Martin> With seperate API calls,
    Martin> it will be much easier for the application to distinguish
    Martin> whether and which additional attributes, group
    Martin> memberships, etc. are available, the application will not
    Martin> have to frob existing API calls in new ways and try to
    Martin> make sense of the results.

I believe that Nico's proposed implementation of a solution to the
problems outlined in my draft actually has this property.
Applications that do not use new API calls will get GSS V2 behavior
when the mechanism provides all functionality required by GSS V2

I agree this is a requirement.

    Martin> Comments on specific sections:

    Martin> Section 2. Kerberos Naming

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

We agree completely on this point.  Is there text in the draft that
caused you to believe I thought otherwise?  Can you suggest additional
text to make this more clear?
    Martin> Remember that ACLs may be large (could be more than a
    Martin> million entries; we have around 40000 entries on some of
    Martin> our systems and we already have customers with 200000
    Martin> entries), so an ACL lookup that would not only require a
    Martin> linear search, but also costly transformations on each
    Martin> entry would be prohibitively expensive.

I completely agree.  You need to be able to have a fixed set of binary
strings you search your ACL for.  When adding an entry to an ACL you
need to easily produce a binary key that can be stored on that ACL and
search for with a hash lookup or other efficient mechanism.

I'd like to see cases where there are multiple identities that a GSS
V3 application searches for on an ACL rather than the single entry
that GSS V2 searches for.  But for large ACLs, you are completely
right that binary comparison is the only way to go.

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

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

    Martin> If Enterprise Names are implemented in a way that they
    Martin> entirely replace the original Kerberos principal names at
    Martin> the GSS-API level, then the existing model would work just
    Martin> fine.  

I agree that you could do this.  However as I discuss, you sometimes
want the enterprise name and you sometimes want the regular principal.
My goal is to give GSS V3 acceptors access to both identities.  You
even discuss this problem later on; I've pulled that text up in my
reply.

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

This argues strongly for allowing GSS V3
applications to get access to both identities so they can make a
decision about which entry goes on the ACL.

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

I agree we could choose this approach for V2 applications.  I agree
that if we do allow V3 applications to get to both identities we will
need to have different OIDs for each identity.

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

For GSS V2 applications, I completely agree with you.  The whole point
of GSS V3 is to add new functionality; that does involve a bit of
complexity.

    Martin> Section 3. X.509 Names

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

Yes.  One of the ways they do this is by including KeyPurposeIDs or
KeyUsage certificate extensions.  We need a way to get access to this
in GSS V3 applications.

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

Probably closer to the second than to the first.  Note however that
there is a PKIX draft based on SRV record tags that would make it
fairly easy to have a SAN for each application.  My belief is that
whatever the decision, GSS V3 applications should be able to get to
all the identifiers they can understand.

I agree that reasonable defaults would be useful here.

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

I actually think many CAs today support the DNSName and RFC822Name
SANs.  But yes, your point is well taken.  I don't see however how
what you are saying is in conflict with what my draft says.

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

We actually had a proposal to do this to improve the GSS V2
experience.  We believed that for GSS V3 native applications, the
application should have access to all possible identities.  There was
no one interested in doing the work to write and implement this
function for V2 applications.  If you would be interested in
documenting it, I think the WG would agree it is a good idea.  If not,
perhaps you can find someone to volunteer.

Either way I don't think this eliminates the need for a V3 solution.

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

Do you believe my draft should discuss character set issues and GSS
naming?

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

Agreed.

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

Agreed.

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

Agreed.  Thus I think ACLs should make this distinction.

    Martin> 4. Composite Name , Name Attibutes

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

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

I agree that if you take advantages of these extensions, you will
either need to have reasonable fall-back behavior or require
mechanisms/infrastructure where the attributes are available.  I
believe we have different applications for which both approaches are
needed.

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

I don't think this is an argument against making information available
to GSS applications.

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

I don't understand how the argument about ACLs and filesystems applies
to my draft in general or to this section in particular.  Can you help
me better understand the connection?

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

Agreed.

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

Sure.  GSS does a great job of that.  However people are now finding
that they want to take a more active role in their applications'
security decisions.  In order to do that, they want to add new
features to GSS.  In other words, GSS has been sufficiently successful
it needs new capabilities.

    Martin> 4.3 Handling of gss_export_name

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

So, I agree it would not be a valid GSS V2 mechanism.  I don't
understand why we cannot expand the scope of GSS mechanisms to deal
with mechanisms from the EAP/AAA space that do not meet all existing
GSS requirements.  The goal is to be able to rite applications that
work with more traditional GSS mechanisms and with these more limited
mechanisms.

I think that is a reasonable goal.

I agree that we need to make it clear that not all applications will
work with these mechanisms.  We need to have clear portability
guidelines and labels.  However I think that GSS is a good API even in
these cases.  I think it would be unfortunate to require people to use
GSS for some mechanisms and some other new API for other mechanisms.

    Martin> 7. Selection of Source Identity

    Martin> This interpretation in the document is somewhat too
    Martin> strict:

I'm sorry I got it wrong; it was based on your comments to the cat and
kitten list.

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

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

I think that having to resolve the name when passed into
gss_inquire_cred is enough of a problem that we want to relax it for
V3.  Or rather I think we may want to be able to resolve the name
given a specific target.

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

We've mostly concluded that changing the behavior of existing apps in
this manner would produce an unacceptable user experience.  We'd rather
V2 mechanisms and apps continue to work as they do because that's what
users and application authors expect.

Thanks so much for your comments.

--Sam

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 20 Dec 2005 15:17:04 -0600

> talking about changing GSS V2 behavior.

Let us be more specific: these are extensions are based on the GSS-API
v2, update 1, but are inteded to form part of the GSS-API v3.

So you might say "these are extensions to the GSS-API v2u1" in a sense,
though they don't actually modify the GSS-APIv2u1.

> the rest of GSS-API somehow in order to take advantage of it in a

Indeed.  Suppose you have a GSS-API application already.  Now you want
to add support for getting at things like {Kerberos V ticket
authorization-data, SAML attributes/assertions, PKIX certificate
extensions, etc...} -- how should you have to modify your existing
GSS-API application to get at such data?

The two choices are:

a) dump the GSS-API, but not the GSS-API mechanisms, and use another API
   to the same mechanisms that provides access to the data you need

or

b) notice that the GSS-API v2 provides three opaque data types that
   could be extended by the addition of functions/methods that operate
   on said opaque data types to provide access to the data you need

   (and term said additional functions/methods a new version of the
   GSS-API)

Now, why on Earth would one want to replace the GSS-API with another API
that provides the same basic functionality plus the required additional
functionality instead of adding functions the base GSS-API v2u1 (and
call it the GSS-API v3)?

And what might preclude (b)?

I think it's clear that there's no reason whatsoever to preclude (b).

Now, that leaves the issue of how best to hook said additional
functionality to the GSS-API:

> [...]

(Clarification for lurkers: here "name" refers to the opaque data type
called "NAME" in the GSS-API, and is very much like an 'object' in that
there are constructor, destructor and accessor methods to deal with NAME
objects.  The existing Java bindings treat the NAME type as an object,
and the C bindings arguably do as well, with the actual C type
implemented as a pointer or an integral object index.)

For all the reasons that Sam gives I agree that GSS-API "names" are the
right place to connect this functionality.

> missing features for GSS V2

The way to do this is to list the features that a valid GSS-API v2
mechanism MUST provide and then state that GSS_Indicate_mechs() MUST NOT
indicate mechanisms which do not provide at least that set of features.

For the rest, I agree with or have little to add to much of the rest of
Sam's reply, so I won't quote it all.

> [...]

I think we should aim for generic extensions, not mechanism-specific
extensions.  Yes, we could add a gss_krb5_authzdata_step() function, or
some such, but that wouldn't be generic, so we'd have different
functions for mechanisms that utilize, say, PKIX credentials, or
something else.  Given that there are folks working of clarifying/
updating SPKM (and or, as I advocate, replacing it with a DTLS-based
mechanism) and that there are folks working on SAML-based GSS-API
mechanisms, all of which may be able to deliver similar "authorization-
data," I think we should aim for a generic API.

Note that the proposed API would not preclude access to raw Kerberos V
Ticket/Authenticator authorization-data.  Indeed, with the proposed
generic API such mechanism-specific extensions are not only not
precluded but may also be provided through the generic functions using
mechanism-specific "name attribute" OIDs.

> [...]

Agreed.

Note too that name attributes need not necessarily have been directly
tied to one's or one's peer's credentials.  The GSS_Get_name_attribute()
function may perform directory lookups to satisfy a particular request,
for example, though it may also obtain the information from an actual
Ticket, certificate, etc...  The particular mechanism used is of little
interest except in so far as establishing trust in the data returned is
concerned -- but I believe the proposal addresses this.

In fact, one might argue, nay, I do hereby argue that there exist
GSS-API v2 applications which do just that: perform directory lookups
relating to a given GSS name to obtain additional data relevant to
authorization, THEREFORE all that extensions such as
GSS_Get_name_attribute() do is opaquely provide an optimization whereby
such data may be delivered by GSS-API mechanisms.

I believe this insight alone should extenguish concerns about ACL
maintenance, etc...

I have examples of such applications.

> [...]

I *strongly* disagree.  See my point directly above.

Thanks so much for your comments, and replies,

Nico
--