Subject: Re: FW: Kerberos Anonymity Support

From: Clifford Neuman <[email-masked]>
Date: Thu, 13 Jul 2006 08:27:42 -0700

Larry,

Here are my thoughts on the anonymity issue w.r.t. authorization data.
I think that what you describe in your revised wording is correct, but
I think that it needs some elaboration.  What follows is my thoughts
on the issues, not specically on your wording, but trying to address
some of the things said in your wording.

w.r.t. being anonymous within a group:

For group membership to be represented by authoirization data, either
the group membership ticket can not be anonymous (i.e. it must
identify the entity authorized to grant a group membership credential
for the particular group), or it may be anonymous within the
kdc-issued element (meaning essentially that it is on the KDC's
authority that the group membership is granted).

Tickets with a kdc-issued element can not have restrictions removed.
I think we need to leave it to the client side to make the
determination whether this violates its confendentiality.  i.e. the
KDC returns a ticket, and the client checks to see what is included
and can use the ticket or choose not to.

If there is not a kdc-issued element, then the KDC is free to remove
any restrictions (i.e. authorization data) it chooses, including
unknown elements, whether or not they appear in an if-relevant.  The
reason is that such a ticket is not conveying any rights based on the
identity encoded in the ticket.

I think we should prepare a table of the known authorization-data
elements, flagged with whether we believe they interfere with client
anonymity.  In doing this exercise, we can think about whether there
is any function served by propagating these elements (i.e. why dont'
we just have all authorization data stripped other than that within a
kdc-issued element).  We may find that the only reason for propagating
such elements is when they are used other than for authorization.

Some other issues on the anonymity draft:

Do we want a form of anonymity that creates a new short lived
anonymous ID that can be renewed so that one can tell later that this
is the same anonymous person that contacted me the last time (i.e. one
that might be usable for short term authorization).  This might change
some of the discussion above.  It would be up to the user to
specifically request such a ticket, and perhaps we would use the same
naming convention, but with a third component that was gensymed at the
point of creation.

Regarding the transided field:

If we have a tiket with a transited encoding of NO-TRANSITED-INFO, is
it allowable for subsequent KDC's to add transited info?  i.e. the
early parts are not carried, but later parts of the path are.

Anonymity and pkinit:

Have we considered the use of pkinit to obtain an anonymous ticket.
One of the early versions of pkinit had the ability to use DH or
similar exchanges during initial authentication, and this could allow
one to obtain an anonymous ticket without even identifying oneself to
the KDC.  I do not think that that particular option made it through
the long raod to pkinit adoption, however.

Section 6:

Typo:

...verify the ticket being used are...

(change to either "tickets", or "is")

Also in security considerations, I think you need a better discussion
of just what is provided in terms of ability to remain anonymous.  In
particular, you shoud spell out what it would take for someone trying
to breach the shield of anonymity to do so.

e.g.

If the KDC that issued an anonymous ticket were to maintain records of
the association of ID's to an anonymous ticket, then someone obtaining
such records could breach the anonymity.  Additionally, the
implementation of most (for now all) KDC's respond to requests at the
time that they are received.  Traffic analasys on the connection to
the KDC will allow an attacket to match client identities to anonymous
tickets issued.  Because there are plaintext parts of the tickets that
are exposed on the wire, such matching by a third party observer is
relatively straigtforward.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 14 Jul 2006 20:58:41 -0700

1) W.r.t comments on the autorization data,  here is the text I came up
with the suggested table.

   Care MUST be taken by the TGS when propagating authorization data to
   ensure that the client confidentiality is not violated: the TGS MUST
   either fail the request or remove authorization data that may reveal
   the client's identity.  An optional authorization element unknown by
   the TGS MUST be removed if it can be ignored (such as ones enclosed
   in the AD-IF-RELEVANT or the AD-KDCIssued containers [RFC4120]).  The
   TGS can strip critical unknown authorization data if such data do not
   convey any rights based on the requesting client's identity.  Here is
   a table of the known authorization-data elements, flagged with
   whether they interfere with client anonymity and recommendations for
   processing them.

         ad-type          References  Can Breach Confidentiality?
     ------------------------------------------------------------------
     AD-IF-RELEVANT        RFC4120     YES, remove if unknown
     AD-KDCIssued          RFC4120     YES, remove if unknown
     AD-AND-OR             RFC4120     YES, remove if unknown
     AD-MANDATORY-FOR-KDC  RFC4120     YES, fail the request if unknown

   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].

2) the authtime, I am attempted to keep the authtime as described in
RFC4120.

   o  If the anonymous ticket is returned in an AS exchange, the
      authtime field of the ticket contains the request time.  If the
      anonymous ticket is returned in a TGS exchange, the authtime field
      of the ticket contains the time of the initial authentication for
      the principal who has made the request.  An anonymous ticket can
      be renewed, and the authtime field of a renewed ticket is the
      authtime in the anonymous ticket that the renewed ticket was based
      on.

3> If we have a tiket with a transited encoding of NO-TRANSITED-INFO, is
it allowable for subsequent KDC's to add transited info?  i.e. the early
parts are not carried, but later parts of the path are.

Yes, this is alowed. here is the text that is unchanged.

   o  The transited field [RFC4120] can contain either the client's
      "normal" authentication path according to Section 3.3.3.2 of
      [RFC4120] or the anonymous authentication path.  If the service
      ticket in a Ticket Granting Service (TGS) request is an anonymous
      ticket with a "normal" authentication path, then the
      authentication path in the reply ticket MUST also contain a
      "normal" authentication path: the TGS MUST add the name of the
      previous realm.  However, if the service ticket in a TGS request
      is an anonymous ticket with an anonymous authentication path, then
      the reply ticket can contain either an anonymous authentication
      path or a "normal" authentication path, based on the local policy
      of the KDC.  Thus a "normal" authentication path in an anonymous
      ticket can be a partial path: it may not include all the
      intermediate realms in the authentication path.  No transited
      policy checking is needed for the anonymous authentication path.
      However, transited policy checks defined in Section 2.7 of
      [RFC4120] would apply to an anonymous ticket that contains a
      "normal" authentication path.

4) Anonymity and pkinit:

Yes, this is supported, I added text to clarify this:

   If there is a key known by both the client and the KDC for encrypting
   the KDC reply, the cname field in the request [RFC4120] can be
   anonymous.  If the client is anonymous and the KDC does not have a
   key to encrypt the reply, the KDC MUST return an error message with
   the code KDC_ERR_NULL_KEY [RFC4120].  Specifically for the AS
   exchange, if the reply key is selected from the client keys (for
   example, as described in Section 3.1.3 of [RFC4120]), then the client
   principal MUST NOT be anonymous.  The anonymous client name, however,
   can be used in conjunction with PKINIT [RFC4556].  An anonymous
   PKINIT client can authenticate the KDC based on the KDC certificate.

5) the typo in section 6 is now fixed.

6) the security consideration section now has your text.

I also attached the draft with all these changes.

Thanks,

-- larry

-----Original Message-----
From: Clifford Neuman [mailto:[email-masked]] 
Sent: Thursday, July 13, 2006 8:28 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: FW: Kerberos Anonymity Support

Larry,

Here are my thoughts on the anonymity issue w.r.t. authorization data.
I think that what you describe in your revised wording is correct, but I
think that it needs some elaboration.  What follows is my thoughts on
the issues, not specically on your wording, but trying to address some
of the things said in your wording.

For group membership to be represented by authoirization data, either
the group membership ticket can not be anonymous (i.e. it must identify
the entity authorized to grant a group membership credential for the
particular group), or it may be anonymous within the kdc-issued element
(meaning essentially that it is on the KDC's authority that the group
membership is granted).

Tickets with a kdc-issued element can not have restrictions removed.
I think we need to leave it to the client side to make the determination
whether this violates its confendentiality.  i.e. the KDC returns a
ticket, and the client checks to see what is included and can use the
ticket or choose not to.

If there is not a kdc-issued element, then the KDC is free to remove any
restrictions (i.e. authorization data) it chooses, including unknown
elements, whether or not they appear in an if-relevant.  The reason is
that such a ticket is not conveying any rights based on the identity
encoded in the ticket.

I think we should prepare a table of the known authorization-data
elements, flagged with whether we believe they interfere with client
anonymity.  In doing this exercise, we can think about whether there is
any function served by propagating these elements (i.e. why dont'
we just have all authorization data stripped other than that within a
kdc-issued element).  We may find that the only reason for propagating
such elements is when they are used other than for authorization.

Do we want a form of anonymity that creates a new short lived anonymous
ID that can be renewed so that one can tell later that this is the same
anonymous person that contacted me the last time (i.e. one that might be
usable for short term authorization).  This might change some of the
discussion above.  It would be up to the user to specifically request
such a ticket, and perhaps we would use the same naming convention, but
with a third component that was gensymed at the point of creation.

If we have a tiket with a transited encoding of NO-TRANSITED-INFO, is it
allowable for subsequent KDC's to add transited info?  i.e. the early
parts are not carried, but later parts of the path are.

Anonymity and pkinit:

Have we considered the use of pkinit to obtain an anonymous ticket.
One of the early versions of pkinit had the ability to use DH or similar
exchanges during initial authentication, and this could allow one to
obtain an anonymous ticket without even identifying oneself to the KDC.
I do not think that that particular option made it through the long raod
to pkinit adoption, however.

Section 6:

Typo:

Also in security considerations, I think you need a better discussion of
just what is provided in terms of ability to remain anonymous.  In
particular, you shoud spell out what it would take for someone trying to
breach the shield of anonymity to do so.

e.g.

If the KDC that issued an anonymous ticket were to maintain records of
the association of ID's to an anonymous ticket, then someone obtaining
such records could breach the anonymity.  Additionally, the
implementation of most (for now all) KDC's respond to requests at the
time that they are received.  Traffic analasys on the connection to the
KDC will allow an attacket to match client identities to anonymous
tickets issued.  Because there are plaintext parts of the tickets that
are exposed on the wire, such matching by a third party observer is
relatively straigtforward.