Re: [secdir] Review of draft-lha-gssapi-delegate-policy-04

[Sam Hartman <[e-mail]>]

>>>>> "Hilarie" == Hilarie Orman <[e-mail]> writes:


    Hilarie> The document describes an augmentation of the semantics
    Hilarie> of the GSSAPI service delegation policy.  It allows a
    Hilarie> client to ask if there is a policy allowing delegation of
    Hilarie> the service.

I'd say it's more like the draft provides a mechanism for a client to
request that the decision about whether to delegate credentials to the
service be made by the GSS-API implementation and the local platform
rather than by the client itself.  Previously, the client needed to
either decide not to delegate or to always delegate.  The local
platform is often in a much better position to make a trust decision
about a service in an infrastructure environment than the client
application.

    Hilarie> This is a something of a policy band-aid.  The API
    Hilarie> currently supports only unconditional delegation.  This
    Hilarie> change allows a client to learn if the local policy
    Hilarie> supports it.  The 
    Hilarie> decision might involve tier of Kerberos
    Hilarie> inter-realm servers, and the API is charged with
    Hilarie> enforcing the policy of assuring that all tickets agree
    Hilarie> that delegation is permitted.

    Hilarie> The change is minimal, involving no over-the-wire
    Hilarie> changes, but I imagine it is only part of the tip of a
    Hilarie> policy iceberg.  


Well, the over-the-wire changes were made years ago.  However, yes,
this does represent an evolutionary step and there are additional
steps in progress.  See
http://k5wiki.kerberos.org/wiki/Projects/Services4User as an example
of a finer grain way of expressing similar policy in the GSS-API
Kerberos mechanism.  (It's not clear how much of that work will be or
requires standardization in the IETF.)


    Hilarie> If clients are to make policy decisions
    Hilarie> about something as complex as delegation, ultimately they
    Hilarie> will need more specific information, I would imagine.
Again, this is about removing that decision from client applications
and placing it in the hands of the platform/infrastructure.


    Hilarie> The security of the mechanism depends on how wise the
    Hilarie> administrators are when configuring the delegation
    Hilarie> policy, but the clients have no insight into how the
    Hilarie> decision was reached.

    Hilarie> I recommend that the security considerations section make
    Hilarie> some comment about why a client would or would not make
    Hilarie> use of this new mechanism.  Perhaps it should be avoided
    Hilarie> for security-critical services ("don't delegate, even if
    Hilarie> it is allowed")?  Or should it always be used?

Avoiding this for security critical services doesn't make sense.  In
general, what is being delegated is permission to act as some given
principal when talking to *any* service.  So, it wouldn't make much
sense to say that the audio service is permitted to act as any
delegated user, but some security critical service is not.  Giving
advice on this topic is quite difficult, because the value of
delegation to a given service depends on a lot of implementation
details (like whether that service will need to access file servers or
the like) which a portable application simply cannot know.  It's
probably reasonable to use this mechanism exceptt when the application
has information that could allow it to make a better decision on its
own.