Subject: draft-ietf-krb-wg-anon-03.txt: section 4, paragraph 8, unknown authorization data

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 19 Mar 2007 01:29:47 -0700

Ken and I discussed the text in section 4, and it became obvious to us
the text in -03 is not clear or may be inaccurate with regarding to
unknown critical authorization. To remedy this, I propose the following
rewrite of paragraph 8:

   During the TGS request, when propagating authorization data in the

   ticket presented or the enc-authorization-data field [RFC4120] in the

   request, care MUST be taken by the TGS to ensure that the client

   confidentiality is not violated.  If an anonymous ticket is returned,

   any authorization element that may reveal the client's identity MUST

   be removed.  The authentication attempt MUST be rejected if there is

   an authorization element that is intended to restrict the use of the

   ticket thus cannot be removed or the local policy prevents the

   removal of an authorization element, and this rule MUST be applied to

   all critical and optional authorization data.  An optional

   authorization element unknown by the TGS MUST be removed if it does

   not potentially convey any rights or limit the rights otherwise

   conveyed in the ticket.  If there is a critical unknown authorization

   element that can potentially restrict the use of the ticket and

   reveal the client identity, the TGS MUST reject the authentication

   attempt instead of propagating the unknown authorization data

   according to [RFC4120].  A critical known authorization element MUST

   be removed if it does not reveal the client identity and it does not

   restrict the use of the ticket.  If the authorization data element is

   intended to amplify the privileges of the principal and it can

   potentially reveals the client's identity, it MUST be removed.  In

   the cases where it is inappropriate to remove an authorization

   element from the TGS request in order to produce an anonymous ticket,

   the KDC MUST return an error message with the code KDC_ERR_POLICY

   [RFC4120], and there is no accompanying e-data defined in this

   document.

--larry