Subject: Kerberos Anonymity ID: authorization data handling rules

From: Larry Zhu <[email-masked]>
Date: Fri, 6 Jul 2007 13:09:23 -0700

This paragraph is hard to understand. The following text is proposed for
-04.

Replace OLD:

   During the TGS request, when propagating authorization data, care

   MUST be taken by the TGS to ensure that the client confidentiality is

   not violated.  If a 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, unless this

   element is encapsulated in a known authorization data element

   amending the criticality of the elements it contains, authentication

   MUST fail according to [RFC4120].  If 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.

With NEW:

   When propagating authorization data in the ticket 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.

   While the rules for processing authorization data in order to

   preserve privacy are specific to the types of authorization data,

   guidelines for the TGS to handle authorization data are provided as

   follows:

   o  Any authorization element that may reveal the client's identity

      MUST be removed unless otherwise specified.

   o  If there is an authorization element that is intended to restrict

      the use of the ticket or limit the rights otherwise conveyed in

      the ticket, the authorization data element cannot be removed in

      order to hide the client's identity.  In this case, the

      authentication attempt MUST be rejected, and the KDC MUST return

      an error message with the code KDC_ERR_POLICY [RFC4120].  There is

      no accompanying e-data defined in this document.  Note this is

      applicable to both critical and optional authorization data.

   o  If there is an unknown authorization element, the TGS MAY remove

      it, or propagate it, or reject the authentication attempt based on

      local policy for that authorization data type.

   The AD-INITIAL-VERIFIED-CAS authorization data [RFC4556] MAY be

   removed from an anonymous ticket based on local policy of the TGS.

Comments are welcome.

---

From: "Aaron D. Jaggard" <[email-masked]>
Date: Sat, 7 Jul 2007 00:23:01 -0500

>    by the TGS to ensure that the client confidentiality is not violated.

I think the concept of "taking care to ensure confidentiality" is too
vague for the use of "MUST"---how does one decide if an implementation
takes sufficient care?  Perhaps either "... request, the TGS (SHOULD |
MUST) protect client confidentiality" or "... request, the TGS is
expected to work to protect client confidentiality" instead?

--Aaron

---

From: Larry Zhu <[email-masked]>
Date: Fri, 6 Jul 2007 23:51:50 -0700

Thanks. The current vague text suggests that it is a judgment call of
the implementers. That might be too harsh as you pointed out.

The following text moves the burden from the implementers to the
protocol designers.

   When propagating authorization data in the ticket or in the enc-
   authorization-data field [RFC4120] of the request, the TGS MUST
   ensure that the client confidentiality is not violated in the
   returned anonymous ticket.  Identities-based authorization data
   typically reveals the client's identity, thus such authorization data
   SHOULD NOT be present in an anonymous ticket.  The specification of a
   new authorization data type MUST specify the processing rules of the
   authorization data when an anonymous ticket is returned.  Unless
   otherwise specified, the TGS MUST process the authorization data when
   an anonymous ticket is returned as follows:

   o  If there is an unknown authorization element, the TGS MAY remove
      it, or propagate it, or reject the authentication attempt, based
      on local policy for that authorization data type unless otherwise
      specified.

What do you think?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Aaron D. Jaggard
Sent: Friday, July 06, 2007 10:23 PM
To: Larry Zhu; [email-masked]
Cc: [email-masked]
Subject: Re: Kerberos Anonymity ID: authorization data handling rules

--Aaron

---

From: Larry Zhu <[email-masked]>
Date: Sat, 7 Jul 2007 11:55:37 -0700

Some additional text is proposed to deal with unknown authorization
data:

   When propagating authorization data in the ticket or in the enc-
   authorization-data field [RFC4120] of the request, the TGS MUST
   ensure that the client confidentiality is not violated in the
   returned anonymous ticket.  The TGS MUST process the authorization
   data recursively according to Section 5.2.6 of [RFC4120] beyond the
   container levels such that all embedded authorization elements are
   interpreted.  Identity-based authorization data SHOULD NOT be present
   in an anonymous ticket in that it typically reveals the client's
   identity.  The specification of a new authorization data type MUST
   specify the processing rules of the authorization data when an
   anonymous ticket is returned.  If there is no processing rule defined
   for an authorization data element or the authorization data element
   is unknown, the TGS MUST process it when an anonymous ticket is
   returned as follows:

   o  If the authorization data element may reveal the client's
      identity, it MUST be removed unless otherwise specified.

   o  If the authorization data element is intended to restrict the use
      of the ticket or limit the rights otherwise conveyed in the
      ticket, it cannot be removed in order to hide the client's
      identity.  In this case, the authentication attempt MUST be
      rejected, and the KDC MUST return an error message with the code
      KDC_ERR_POLICY [RFC4120].  There is no accompanying e-data defined
      in this document.  Note this is applicable to both critical and
      optional authorization data.

   o  If the authorization data element is unknown, the TGS MAY remove
      it, or transfer it into the returned anonymous ticket, or reject
      the authentication attempt, based on local policy for that
      authorization data type unless otherwise specified.  If there is
      no policy defined for a given unknown authorization data type, the
      authentication MUST be rejected.  The error code is KDC_ERR_POLICY
      when the authentication is rejected.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Larry Zhu
Sent: Friday, July 06, 2007 11:52 PM
To: Aaron D. Jaggard; [email-masked]
Subject: RE: Kerberos Anonymity ID: authorization data handling rules

What do you think?

-----Original Message-----

--Aaron