GSS-API and libkrb5 behavior for Anonymous tickets

Sam Hartman hartmans at MIT.EDU
Wed Nov 4 16:13:25 EST 2009


>>>>> "Jeffrey" == Jeffrey Hutzelman <jhutz at cmu.edu> writes:

    Jeffrey> --On Tuesday, November 03, 2009 11:41:55 AM -0600 Nicolas
    Jeffrey> Williams
    Jeffrey> <Nicolas.Williams at sun.com> wrote:

>    Just because the mechanism can do that doesn't mean it should.  I'd
    >> rather treat the anon req_flag as critical in the mechanism
    >> implementations, even though from the application's p.o.v. it's
    >> optional.

    Jeffrey> Me too.

    Jeffrey> Normally, we tell application implementors to check the
    Jeffrey> return state and not use a context that doesn't meet the
    Jeffrey> application's needs; this allows applications lots of
    Jeffrey> flexibility in asking for the moon and using what they
    Jeffrey> can get.  However, anon_req is qualitatively different
    Jeffrey> here, in that if you request an anonymous context,
    Jeffrey> complete context establishment, and end up with a
    Jeffrey> non-anonymous context, you've given away the farm even if
    Jeffrey> you don't use the context.  Now, we provide applications
    Jeffrey> a way to prevent this by indicating anon_state early
    Jeffrey> enough that they can decline to send a token along that
    Jeffrey> would reveal the client's identity.  But, I'm inclined to
    Jeffrey> think it's better (safer) for mechanisms simply not to
    Jeffrey> establish a context at all if anonymity is requested and
    Jeffrey> cannot be provided.

If you're going to do the work to standardize this behavior, I wouldn't mind much, although I probably would mildly disagree.

However, I disagree fairly strongly unless this is going to be
accompanied by an update to 2743.  My argument is that it breaks
conforming GSS-API applications.  If I'd prefer anonymous but would be
willing to accept an authenticated context, then I would end up
failing with your mechanism.  If I'm writing a portable application I
have to check the output flag anyway, even if some mechanisms do offer
this behavior.

So, with your approach, you complicate the life of every portable application.
That seems poor.



More information about the krbdev mailing list