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