Requesting Anonymous as a client

Greg Hudson ghudson at MIT.EDU
Mon Dec 21 22:01:52 EST 2009

I have a few new thoughts on this after considering fully anonymous vs.
semi-anonymous principals.  Sam's project is only to implement full
anonymity, but we want to think ahead to both cases when we consider
APIs and UIs.

>From a protocol perspective, you request anonymous tickets by setting
the anonymous KDC option, and you choosen between semi-anonymous vs.
fully-anonymous via the client name field: WELLKNOWN/ANONYMOUS for full
anonymity, and a real principal name for semi-anonymity.

If we were implementing both kinds of anonymity at once, we would
definitely need a flag to indicate anonymity, both in the API and the
UI.  In the API, it would be reasonable to differentiate between semi-
and full anonymity via the principal name; in the UI, that would be less
attractive.  One possibility for the UI would be to map the empty
principal name to the anonymous principal name if the anonymous flag is
specified.  With those assumptions (and assuming the UI flag is -n), we
would have:

  * Anonymous flag set, anonymous principal name: full anonymity
  * Anonymous flag set, other principal name: semi-anonymity
  * Anonymous flag unset, other principal name: normal AS request
  * Anonymous flag unset, anonymous principal name: (debatable)

  * "kinit -n": full anonymity, default realm
  * "kinit -n WELLKNOWN/ANONYMOUS": full anonymity, default realm
  * "kinit -n @realm": full anonymity, specified realm
  * "kinit -n WELLKNOWN/ANONYMOUS at realm": full anonymity, specified realm
  * "kinit -n princname": semi-anonymity, default realm
  * "kinit -n princname at realm": semi-anonymity, specified realm
  * "kinit WELLKNOWN/ANONYMOUS at realm" (or without realm): (debatable)

The remaining question is whether it's more elegant to demand that the
option be explicitly set for anonymous requests, or to (as Sam proposes)
allow implicit fully anonymous requests by specifying the anonymous
principal name.  If we allow implicit anonymous requests, we don't
really need the API flag until we implement semi-anonymity (but we do
still want the UI flag, probably).

At the moment I lean weakly towards disallowing implicit anonymous
requests, since it feels wrong to make use of a heuristic which only
applies to half of the problem space.

More information about the krbdev mailing list