GSS-API and libkrb5 behavior for Anonymous tickets

[Sam Hartman]

>>>>> "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.