Subject: anonymous tickets (was Re: Section 2 (take 2) Kerberos Revisions for comment)

From: Ken Raeburn <[email-masked]>
Date: 23 Nov 2000 23:12:51 -0500

> <h3>2.8 Anonymous Tickets</H3>
> 
> When policy allows, a KDC may issue anonymous tickets for the purpose
> of enabling encrypted communication between a client and server
> without identifying the client to the server.  Such anonymous tickets
> are issued with a generic principal name configured on the KDC
> (e.g. "anonymous@<realm>") and will have the ANONYMOUS flag set.  A
> server accepting such a ticket may assume that subsequent requests
> using the same ticket and session key originate from the same user.
> Requests with the same username but different tickets are likely to
> originate from different users.  Users request anonymous ticket by
> setting the REQUEST-ANONYMOUS option in an AS or TGS request.

How does this work in an AS request?

If I send in an AS_REQ for raeburn@REALM with the REQUEST-ANONYMOUS
flag set, is the AS_REP for anonymous@REALM encrypted using my key?
If the client name I supplied needs canonicalization, how do I know
what value to use as a salt in computing my key from my password?

I'm assuming I can't request anonymous tickets for anonymous@REALM,
since either the password is published, so the session key
distribution is insecure, or it's restricted, in which case it's not
really "anonymous", more like a group account.

Perhaps we should append to the first paragraph above (in 2.8):

	If the KDC issues an AS reply with anonymous tickets, the
        reply is still encrypted using the specified user's private
        key; thus, a PA-PW-SALT preauth datum might need to be
        included, if the principal name is used as salt data for
        producing the key from the user's password.

And how is a service supposed to behave when presented with anonymous
tickets?

If a service is simply recording principal names as an audit trail, it
now must be rewritten to reject anonymous tickets.  Or the KDC should
refuse to issue anonymous tickets for that service, though we don't
have a good error code to return for that case except KRB_ERR_GENERIC.
Perhaps we should add:

(to text for KDC option REQUEST-ANONYMOUS)

	If the local realm's policy does not permit anonymous
	credentials, the request is to be rejected with the
	KRB_ERR_NO_ANONYMOUS error code.

(to text for ticket flag ANONYMOUS)

	If the service does not permit anonymous access, credentials
	with this flag set should be rejected with the
	KRB_ERR_NO_ANONYMOUS error code.
(and perhaps)
	The default configuration for an implementation SHOULD be to
	reject anonymous credentials unless the application service is
	specifically configured otherwise.

(to error code list)

	KRB_ERR_NO_ANONYMOUS    ##   Anonymous credentials not permitted

where of course specification of the number is left to the Kerberos
Assigned Numbers Authority (i.e., Cliff).  :-)

Related to this, I don't think we specify anywhere what should be done
if unrecognized flags are set in the KDC options or ticket flags.
Because of potentially risky behavior with flags like ANONYMOUS, I'd
suggest that unknown flags should causes errors.  But applying that
retroactively, to for example the CANONICALIZE flag, could completely
break compatibility between RFC1510 and RFC1510bis code because the
CANONICALIZE flag is needed for maximum interoperability.  We could
just hope that no one adds such drastic options ever again....

(Random thought: Since we'll need CANONICALIZE pretty much all the
time, maybe canonicalization should just become the default behavior,
and maybe a NO-CANONICALIZE flag added if it's really necessary.)

Add to end of ticket flags description:

	Any flags listed above as reserved, and flags after the first
	32 bits, that are set in a received ticket SHOULD cause the
	ticket to be rejected, since it is possible (as with the
	ANONYMOUS flag) that an unknown flag could indicate a
	situation of lessened security than the application writer
	anticipated might arise.

Add to end of KDC options description:

	Any option bits not given specific definitions above (all
	those listed as "unused" or "reserved", and any added after
	the first 32 bits) may be ignored by the KDC.  It is the
	responsibility of the client to determine whether the KDC
	heeded any requested options.

... although I don't know if that's compatible with the PK-Cross
requirements.  Will a KDC not implementing PK-Cross break things if it
ignores those option bits, or will it be required to give a certain
error if they're set?

Ken