Subject: Kerb anonymity support 01 changes

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 6 Mar 2006 05:00:31 -0800

-01 was submitted and it contains the following additions since -00:

1) a non-empty anonymous principal name.
2) support of pseudo-anonymity.
3) a new section on GSS-API implementations of the kerberos anonymity
support.

Things are not included: un-identifiability within a clearly constrained
group, or rather at present such constrained groups are limited to the
client realms.

Here is the breakdown of the diff output.

154,156c154,163
<       [RFC4120], and the name-string is an empty SEQUENCE (this client
<       principal name is referred hereafter as the anonymous client
<       principal name in this document).
---
>       [RFC4120], and the name-string is a sequence of three
>       KerberosString components: "ANONYMOUS", "ANONYMOUS", and
>       "ANONYMOUS".  This client principal name is referred hereafter
as
>       the anonymous client principal name in this document.  A note on
>       why this anonymous principal was chosen historically: at the
time
>       of writing it was believed that there exist implementations that
>       do not handle empty sequences as principal names correctly thus
>       using an empty sequence as the anonymous principal name, that
can
>       be otherwise perceived as a more natural choice, could create a
>       security weakness for these implementations; the anonymous

Here I proposed the non-empty printable anonymous principal name.

158d164
<    o  The client realm name is an empty KerberosString [RFC4120].
160,163d165
<    o  The tr-type field of the transited field [RFC4120] is NO-
<       TRANSITED-INFO (as defined later in this section) and the
contents
<       field is an empty OCTET STRING.  No transited policy is defined
<       for anonymous tickets.

< Internet-Draft         Kerberos Anonymity Support           October
2005
---
>       principal is therefore chosen to be both non-empty and
>       exceedingly-unlikely-to-have-been-used so as to maximize
backward
>       compatibility for deployed implementations.
> 
>    o  The client realm name is an empty KerberosString [RFC4120].
170a178,192
>    o  The transited field [RFC4120] can either contain the client's
>       authentication path or contain the anonymous authentication path
>       defined as follows: the tr-type field of the transited field is
>       NO-TRANSITED-INFO (as defined later in this section) and the
>       contents field is an empty OCTET STRING.  If a TGS request
>       contains an anonymous ticket with a "normal" authentication path
>       (i.e. the transited field does not contain the anonymous
>       authentication path as defined above), then the reply ticket, if
>       any, MUST NOT contain the anonymous authentication path.  For
>       application servers, no transited policy is defined for the
>       anonymous authentication path, but all of the transited checks
>       would still apply if an anonymous ticket contains a "normal"
>       authentication path.  Note that the "normal" authentication path
>       in an anonymous ticket can be a partial path, thus it may not be
>       used to identify the originating client realm.
172c194,196
<    o  It contains no information that can reveal the client's
identity.
---
>    o  It contains no information that can reveal the client's identity
>       other than, at most, the client's realm or the realm(s) on the
>       authentication path.
185c209,210
<    specification if the ticket is not an anonymous ticket as defined.
---
>    specification if the ticket is not an anonymous ticket as defined
in
>    this section.
195a221,227

Here is the pseduo-anonymity, that Jeff and Nico asked for.

200a233,235
>    Note that the server principal name and the server realm in a
cross-
>    realm referral TGT are not dependent on whether the client is the
>    anonymous principal or not.
201a237

A note based on Love's email.

---
> 5.  GSS-API Implementation Notes

---
>    At the GSS-API level, the use of an anonymous principal by the
>    initiator/client requires a software change of the initiator/client
>    software (to assert the "anonymous" flag when calling
>    GSS_Init_Sec_Context().
267a304,346
>    GSS-API does not know or define "anonymous credentials", so the
>    (printable) name of the anonymous principal will rarely be used by
or
>    relevant for the initator/client.  The printable name is relevant
for
>    the acceptor/server when performing an authorization decision based
>    on the name that pops up from GSS_Accept_Sec_Context() upon
>    successful security context establishment.
> 
>    A GSS-API initiator MUST carefully check the resulting context
>    attributes from the initial call to GSS_Init_Sec_Context() when
>    requesting anonymity, because (as in the GSS-API tradition and for
>    backwards compatibility) anonymity is just another optional context
>    attribute.  It could be that the mechanism doesn't recognize the
>    attribute at all or that anonymity is not available for some other
>    reasons -- and in that case the initiator must NOT send the initial
>    security context token to the acceptor, because it will likely
reveal
>    the initiators identity to the acceptor, something that can rarely
be
>    "un-done".
> 
>    GSS-API [RFC2743] defines name_type GSS_C_NT_ANONYMOUS to represent
>    an anonymous identity.  In addition, according to Section 2.1.1 of
>    [RFC1964] the string representation of the anonymous client
principal
>    name can be "ANONYMOUS/ANONYMOUS/ANONYMOUS" with the name_type
>    GSS_KRB5_NT_PRINCIPAL_NAME.  Implementations conforming to this
>    specification MUST accept both forms and consider them equivalent.
> 
>    Portable initiators are RECOMMENDED to use default credentials
>    whenever possible, and request anonymity only through the input
>    anon_req_flag to GSS_Init_Sec_Context().
> 
> 

A section was added on GSS-API implemenations. Mostly taken from Martin
email to the list.

> 
> 6.  Security Considerations
> 
>    Since KDCs ignore unknown options [RFC4120], a client requiring
>    anonymous communication needs to make sure that the ticket is
>    actually anonymous.  A KDC that that does not understand the
>    anonymous option would not return an anonymous ticket.
> 

A reference was added

276a356,359
>    In cases where specific server principals must not have access to
the
>    client's identity (for example, an anonymous poll service), the KDC
>    can define server principal specific policy that insure any normal
>    service ticket can NEVER be issued to any of these server
principals.
279,281c362

Martin asked for this.