Subject: Re: [Ietf-krb-wg] Kerberos anonymity and GSS-API names

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 17 Sep 2008 17:31:39 -0400

--On Monday, August 25, 2008 10:46:02 AM -0500 Nicolas Williams 
<[email-masked]> wrote:

> On Mon, Aug 25, 2008 at 05:22:43PM +0200, Martin Rex wrote:
>> Jeffrey Hutzelman wrote:
>> > Is the lack of GSS_S_ANONYMOUS_FLAG sufficient for this purpose?  I
>> > hope  so, because it is the only indication of failure to establish an
>> > anonymous  context that is provided for in RFC2743.
>>
>> The absence of GSS_C_ANYMOUS_FLAG (my original typo) from the resulting
>> security context attribute is IMHO a requirement for partial anonymous
>> authentication.
>
> I agree.
>
>> But how should the calling initiator distinguish a fallback
>> partial-anonymous from a regular client-to-server authentication?
>> Inquiring the security context for the initiator name might work for
>> some implementations, but I REALLY dislike the idea of having the
>> initiator parse the result of gss_display_name() and perform a string
>> compare of a component.
>
> I asked separately about this.  Portable applications wouldn't care if
> the non-anonymous initiator name is a partially anonymous name because
> there is no non-mechanism-specific way to indicate this.  A new flag
> would help in that case.
>
> Applications using the Kebreros V mechanism could simply display the
> initiator name and parse it, IF there is a standard display syntax for
> partially anonymous krb5 princ names.
>
>> I would really prefer a different approach.
>>
>> If we believe that the concept of _one_ single and obvious
>> partial-anonymous authentication is generic, we could try to define it
>> in a generic and portable fashion at GSS-API (one additional nametype,
>> one additional context attribute flag).
>
> I think that would be a good approach.
>
>> Another approach would be to consider "partial-anonymous" to be
>> something like a group membership (in the discussed case, that group
>> is probably the entire realm), then we could define one or more
>> specific nametype for this purpose "partial-anonymous-group" and
>> "smear" the functionality across the gssapi calls
>> gss_import_name(), gss_acquire_cred() and gss_init_sec_context().
>
> GSS_Display_name() is where we run into trouble that way :)  This is
> avoided by adding a new context flag, which I see you propose.
>
>> At the generic level:
>>
>> One additional security context attribute GSS_C_ANONGROUP_FLAG to request
>> (on input) or to indicate (on output) partial-anonymity based on group
>> membership.
>>
>> gss_import_name(NT=partial_anonymous_group,name="") to result
>> in a partial-anonymous name idenifying the the default group.
>
> Given the new context flag, I'd expect  GSS_C_NO_NAME/
> GSS_C_NO_CREDENTIAL to also work.
>
>> gss_import_name(NT=partial_anonymous_group,name="group-name") to
>> result in a partial-anonymous name identifying the explicit group
>> "group-name".
>
> Ah, I see where the group-name comes in.
>
>> ...just a thought.
>
> I like it.
>
> Nico

OK; here's where I think we stand on the whole A022/A023/A030 mess...

- A client requests a fully-anonymous context using anonymous flag.
  As usual for GSS-API, the resulting context may actually be fully
  anonymous, partially anonymous, or not anonymous at all.  However,
  GSS_S_ANONYMOUS will be set only on fully-anonymous contexts.

- It has been suggested that we include text allowing implementations
  to provide an implementation-dependent way of requesting the use
  of a partially-anonymous context.

- It has been suggested that we specify a mechanism-specific but
  implementation-independent way of requesting the use of a
  partially-anonymous context, such as by using a partially-anonymous
  name along with the GSS_S_ANONYMOUS flag.

- Martin has proposed defining a new context flag at the GSS-API
  level which would be used to request and indicate partially
  anonymous contexts in a mechanism-independent way.

- Fully anonymous names will be exported and displayed with name type
  GSS_C_NT_ANONYMOUS.  We have not specified the display format for
  Kerberos names of this type, but Martin believes we need to do so.
  This is (still) issue #A023.

- Partially-anonymous names can be imported using the name type
  GSS_KRB5_NT_PRINCIPAL_NAME with the standard syntax, and will be
  exported and displayed with this type.

- Martin has proposed defining a new name type at the GSS-API level
  which could be used to import partially-anonymous names in a
  mechanism-independent way, and presumably also for display.

In the interest of getting this resolved, I will propose we do all of the
following:

(a) Specify a mechanism-specific means of requesting a partially
    anonymous context.  Specifically, replace -09 s.6 p.2 with:

        At the GSS-API [RFC2743] level, an initiator/client requests
        use of an anonymous principal with a non-anonymous realm by
        calling GSS_Init_sec_context with an initiator credential
        for such a principal and asserting the anon_req_flag.  It
        requests the use of an anonymous principal with the
        anonymous realm by calling GSS_Init_sec_context with any
        other initiator credential or with GSS_C_NO_CREDENTIAL and
        asserting the anon_req_flag.  However, the anon_state flag
        MUST be asserted only for a context which uses an anonymous
        principal with the anonymous realm name.

(b) Specify the display form for anonymous Kerberos principals to
    be the same as that for GSS_KRB5_NT_PRINCIPAL_NAME.

(c) Take Martin's proposals for a new name type and context flag
    to the KITTEN WG as a separate item.  When these are defined,
    implementations of the Kerberos mechanism will be free to
    support them.  (Martin/Nico, would you be willing to write
    an internet-draft for this?)

Comments?  Agree?  Disagree?

-- Jeff
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Sep 2008 22:22:11 -0400

My personal opinion is that partial-anonymous is mechanism-specific
and that we don't have guidance to give on GSS-API behavior in the
general case.  In the specific case of Kerberos I'd assume you would
check for partial anonymous by calling gss_display_name and looking at
the result (Love, Martin, I realize this is not particularly defined,
but it does work in practice) or more correctly call gss_export_name
and parse the ASN.1.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 17 Sep 2008 22:57:28 -0500

>  GSS_S_ANONYMOUS will be set only on fully-anonymous contexts.

Yes.

>  of a partially-anonymous context.

Hmmm.  How?  Through additional req_flags/ret_flags?  That requires
standardization.  Through a standard anonymous/partially anonymous name
display syntax that applications can understand?  That requires
standardizing the mechanism's anonymous name display syntax, but that's
no big deal.  Any other extension would be fine, but non-portable.

>  name along with the GSS_S_ANONYMOUS flag.

I think it's sufficient to use a credential handle whose cred_name is a
partially anonymous name.  That's mechanism-specific, but portable
across implementations provided that there's a standard display name
syntax.

>  anonymous contexts in a mechanism-independent way.

I'm fine with that, but it's probably not powerful enough.  What does
"partially anonymous" mean in the context of PKIX names, DNs in
particular?  I'm afraid a ret_flag would only be enough to tell the app
to check the src_name of the resulting security context, but if the app
wanted partially anonymous names in the first place, then it had better
know to do so anyways.

So I think new flags are not sufficient, and not necessary.

>  This is (still) issue #A023.

IMO the Kerberos V mechanism should display anon and partially anon
names with the GSS_KRB5_NT_PRINCIPAL_NAME name-type's display syntax.

>  exported and displayed with this type.

Yes.

>  mechanism-independent way, and presumably also for display.

Yes, that's a very good idea.  Of course, "partially anonymous" may mean
rather different degrees of anonymity for different mechanisms, so
applications that care about partial anonymity will still need to have
mechanism-specific knowledge OR interact with users ("Is this name
sufficient anonymous for your purposes?").

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 18 Sep 2008 17:49:09 +0200 (MEST)

> but it does work in practice) or more correctly call gss_export_name
 
Which ASN.1?  the exported name format/syntax is defined by the
Kerberos 5 gssapi mechanism spec and does not contain any ASN.1.
Aside from the non-ASN.1 generic framing of the exported name
it looks very much like a printable Kerberos principal name.

Essentially, what I'm asking for is the following:
Kerberos 5 is (still?) an authentication scheme that relies
entirely on name-based authentication, and a Kerberos principal
name is composed of two parts, a realm part refering to a
particular administrative domain (Kerberos realm) and
associated database (kdb), and a principal part which refers
to an entry in that database.

IMHO, it is necessary to standardize the various levels of
anonymity at the Kerberos 5 protocol level, so I think it comes
naturally to reproduce this at the gssapi level where those
Kerberos principal names become visible.

About the general question: what is anonymity anyways?
Anonymity is IMHO the ability to "blend within a group".
Full anonymity means that theoretically you can only assume that it
is from an intelligent life form or from a machine instructed
by an intelligent life form.  In practice you can characterise
that group much better for various reasons, as described
in the security considerations.

A "partial anonymous" authentication means that the group
is clearly defined.  What a group is, or what groups are possible
probably depends on the gssapi mechanism.

In the current Kerberos 5 protocol, there seems to be only
one obvious group at the moment, and that is "the Kerberos realm".

Further grouping in Kerberos 5 is conceivable, but does not seem
to be standardized so far.

-Martin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 18 Sep 2008 13:23:33 -0400

> no big deal.  Any other extension would be fine, but non-portable.

Yes; that's what "implementation-dependent" means.

> across implementations provided that there's a standard display name

Sam had indicated he didn't think it was a good idea for the mechanism to 
assert a KDC option merely based on the caller's use of a particular 
principal name.  The response I remember reading (and recall, you're 
quoting my summary of the situation, not my own arguments) was to suggest 
that the anon_req_flag would still be required for the KDC option to be 
asserted.

Of course, you replied to my summary of the situation, which was intended 
to be informational and not a source of rehashing the points already 
discussed, but not to the concrete proposal.  Can I get some comments on 
that, please?

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 18 Sep 2008 12:48:44 -0500

> Yes; that's what "implementation-dependent" means.

There were several questions there.

Of particular interest: "Through additional req_flags/ret_flags?"
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 18 Sep 2008 12:50:52 -0500

> that the anon_req_flag would still be required for the KDC option to be 

Sam's correct, but that doesn't mean we must add a req_flag when instead
we can use the name-type of the credential handle's desired_name/cred_name.

> discussed, but not to the concrete proposal.  Can I get some comments on 

Sure.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 18 Sep 2008 16:54:12 -0400

> There were several questions there.

Yes there were.  The proposal was to add specific text which says that an 
implementation MAY provide implementation-specific means to request a 
partially-anonymous context.  It didn't suggest any particular means, but 
"implementation-dependent" sort of implies something not standardized.  I 
would point out that since there is no GSS-API ABI, adding additional flags 
at the API level does _not_ require standardization; just use a bit that 
you're not using for any of the standard flags.

In any case, this is only relevant if we don't define a standard way of 
requesting a partially-anonymous context.  Which is one of the open 
questions.

-- Jeff

---

From: Larry Zhu <[email-masked]>
Date: Fri, 19 Sep 2008 01:03:13 -0700

>        principal with the anonymous realm name.

In the partial anonymous case, the caller does not have a way to know if the partial anonymous is achieved. This seems likely to create confusions and/or inconsistency. We should standardize the whole 9 yards or nothing.

As Martin recently summarized very well that the partial anonymous is the quick-"dirty" way to implement groups. Given groups are not standardized in Kerberos, it seems a bridge-too-far to standardize the partial-anonymous in the API level here.

>    be the same as that for GSS_KRB5_NT_PRINCIPAL_NAME.

This does not work because commercial implementations may require that the display name must be localized. I would expect the French would insist the display name for the anonymous principal as "anonyme" or "sans nom". I don't think we can use GSS_KRB5_NT_PRINCIPAL_NAME to get a localized name any well-known names.

Because of that reason, I suggest we should not standardize display names for any well-known names.

--larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Hutzelman
Sent: Wednesday, September 17, 2008 2:32 PM
To: Nicolas Williams; Martin Rex
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ietf-krb-wg] Kerberos anonymity and GSS-API names

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 19 Sep 2008 10:45:09 -0400

--On Friday, September 19, 2008 01:03:13 AM -0700 Larry Zhu 
<[email-masked]> wrote:

> In the partial anonymous case, the caller does not have a way to know if
> the partial anonymous is achieved. This seems likely to create confusions
> and/or inconsistency. We should standardize the whole 9 yards or nothing.

Agree.  If we standardize a way of requesting a partial anonymous context, 
we must also standardize a way of knowing that it has been achieved.  It 
seems to me that successful context establishment with a 
partially-anonymous credential should be a sufficient indication.  The test 
for anon_state is required for fully-anonymous contexts because you can use 
a non-anonymous or default credential to request a fully-anonymous context. 
But, a partially anonymous context can be requested only with a 
partially-anonymous cred.

> As Martin recently summarized very well that the partial anonymous is the
> quick-"dirty" way to implement groups. Given groups are not standardized
> in Kerberos, it seems a bridge-too-far to standardize the
> partial-anonymous in the API level here.

I actually think we can defer the question of whether to standardize at the 
GSS-API level, and if so, how, without having to block this document. 
Also, I think both that question and any work it spawns belong in KITTEN, 
not here.

> This does not work because commercial implementations may require that
> the display name must be localized. I would expect the French would
> insist the display name for the anonymous principal as "anonyme" or "sans
> nom". I don't think we can use GSS_KRB5_NT_PRINCIPAL_NAME to get a
> localized name any well-known names.
>

Again, I think you're conflating two different things.  If implementations 
want/need to localize what they display to users for an anonymous name, 
they can do so, based on the name type.  The question of whether the string 
returned by GSS_display_name is standardized is a separate one.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Tue, 23 Sep 2008 15:24:13 -0400

>>>>> "Larry" == Larry Zhu <[email-masked]> writes:

    Larry> Jeff wrote:
    >> larry zhu wrote: > Because of that reason, I suggest we should
    >> not standardize display names > for any well-known names.
    >> Again, I think you're conflating two different things.  If
    >> implementations want/need to localize what they display to
    >> users for an anonymous name, they can do so, based on the name
    >> type.  The question of whether the string returned by
    >> GSS_display_name is standardized is a separate one.

    Larry> If we use the GSS_KRB5_NT_PRINCIPAL_NAME mechanism in
    Larry> RFC1964 to generate the display name, we will get the
    Larry> anonymous name displayed as "WELLKNOWN/ANONYMOUS".

This seems reasonable to me.

    Larry> If we say the string returned by GSS_display_name() for the
    Larry> anonymous principal must be "XYZ" in -10, does an
    Larry> implementation have the ability to localize this string
    Larry> "XYZ"? 

No, the implementation may not localize what gss_display_name returns.
Applications however may localize the results.

<

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 23 Sep 2008 16:05:41 -0400

> Applications however may localize the results.

Yup.  Note that while the proposal is for GSS_display_name to return a 
name_string corresponding to the syntax of GSS_KRB5_NT_PRINCIPAL_NAME, for 
fully anonymous principals the name_type it returns will be 
GSS_C_NT_ANONYMOUS.  So, applications can key on the name type and present 
anonymous principals to the user however they want.

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Tue, 23 Sep 2008 22:12:00 +0200 (MEST)

> Applications however may localize the results.

Localizing textual error message (at the gssapi) is fine, because
they're normally created as numbers, processed as numbers, and only
displayed as text to humans or written to logfiles.

For names, on the other hand, localization is IMHO a pretty bad idea.
It's true that they're displayed to humans as well, but I think they
should always be locale-indepent, and in particular when they're
used for name-based authentication, such as with GSS-API and with
Kerberos, because then they're supposed to be more like pictures
or faces, rather than words or verbose descriptions.

I know that gss_display_name() is specified to be for human display
and that it was originally intended to be subject to localization
primarily for localization of attribute labels in distinguished names
rather than for localization of Kerberos principal names. 

But if you look closely at the idea of localizing attribute labels
in distinguished names -- that is not localizing the name! -- it
is localizing the structuring elements in the name (and would be
equivalent to localizing the '@' and '/' characters in Kerberos
principal names).

I don't think that Kerberos principal names should be localized
in any way by gss_display_name() -- ever.  No service principals
like "host/" or "krbtgt/" and neither any wellknown or anonymous
principals -- in case they're ever to be processed and emitted
by gss_display_name().

For the "fully anonymous" name, the returned anonymous
nametype oid should be sufficient for gss_display_name() and
any localization be left entirely to the application.  But again,
I think that localization of Kerberos principal names is always bad idea,
and will only result in *lots* of frustration in multinational companies.

Localizing Kerberos names is about as bad as asking people to rename
their Web-Servers addresses to start with a localized equivalent
of "wwww".  But what localization would you require -- geographical
location of the Server?  TLD?  Home/Headquarter of the owner?

Globally adopting the names from the Inventors/Owners instead of
inventing localized versions is extremely reasonable, not just for
physical units, but also for names (apple,ibm,microsoft,www) or
new technologies (Internet,CD,DVD,PC) and benefits the entire
mankind.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Tue, 23 Sep 2008 16:28:35 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Localizing textual error message (at the gssapi) is fine,
    Martin> because they're normally created as numbers, processed as
    Martin> numbers, and only displayed as text to humans or written
    Martin> to logfiles.

    Martin> For names, on the other hand, localization is IMHO a
    Martin> pretty bad idea.  It's true that they're displayed to
    Martin> humans as well, but I think they should always be
    Martin> locale-indepent, and in particular when they're used for
    Martin> name-based authentication, such as with GSS-API and with
    Martin> Kerberos, because then they're supposed to be more like
    Martin> pictures or faces, rather than words or verbose
    Martin> descriptions.

I don't think your argument applies to well-known names like anonymous
as much as it does to other name types.

    Martin> I know that gss_display_name() is specified to be for
    Martin> human display and that it was originally intended to be
    Martin> subject to localization primarily for localization of
    Martin> attribute labels in distinguished names rather than for
    Martin> localization of Kerberos principal names.

However the string anonymous seems as much a structural element as the
string organizationalUnit.
An anonymous name happens to be all structural.

I can totally understand why a gss-api application would want to
display the word anonymous in the current locale rather than
displaying the ascii string anonymous.  It needs to distinguish that
string from all other names.  For example you could have a interface
that displayed names like "Sam Hartman (user)" or "Administrators
(group" where the strings in parenthesis are localized.  Such an
interface could display "(Anonmyous)" or "Anonymous" with no
non-structural part.  It would be reasonable to localize that string in my opinion.

Where I think Larry and I disagree is about where that localization
happens.  I think that despite the intention of some GSS-API designers
people do use the output of gss_display_name in ways for which
localization of Kerberos principals would be highly problematic.  So,
I don't think that's the best place  to do the localization.

I'll note that this may be a case where the usage patterns of SSPI and
GSS-API differ enough that you would adopt different conventions.  I
don't understand SSPI conventions enough to comment on whether
localizing anonymous in their display name function would be
reasonable.  In general, I would prefer for SSPI and GSS-API not to
diverge.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 23 Sep 2008 15:33:55 -0500

> I don't think that's the best place  to do the localization.

Right, so we can always add GSS_Display_name_localized() if we really
care.

Apps cannot localize names unless the number of names to localize is
small and their display syntax *trivial* and easily recognized.

For now I propose that we either rule L10N out of scope for
GSS_Display_name() or add GSS_Display_name_localized().

> reasonable.  In general, I would prefer for SSPI and GSS-API not to

Windows localizes names like "Administrator".  I don't know if that
happens below or above the SSPI.

Nico

---

From: Martin Rex <[email-masked]>
Date: Tue, 23 Sep 2008 22:54:48 +0200 (MEST)

> An anonymous name happens to be all structural.

Personally, I think of anonymous to describe the largest possible
group to blend in.  I certainly don't have a problem with a
localized description for a group (or a Kerberos principal),
but I do have one with the localization of the name itself.

> displaying the ascii string anonymous.

I agree about describing to the user in a localized fashion
that an anonymous authentication was performed.  I disagree that
this should be done by localizing the name.  In fact, if you
retain the name anonymous through all locales and the app
displays both, the localized description and the globally standardized
name, everyone will be able to recognize the name in all possible
locales -- and everyone will be better off in the end.

> reasonable.  In general, I would prefer for SSPI and GSS-API not to

SSPI does have more than one API call for that purpose.  :)

I asked for (and received) the QueryContextAttributes(NATIVE_NAMES)
during W2K Beta.   If the app calls QueryContextAttribute(NAMES),
it will receive the local account name to which the authentication
resolved (which may be something entirely different than the
kerberos principal name of an underlying Kerberos authentication
 -- not because of localization, but because there may be a mapping
of an (externel) Kerberos principal to a (local) account name --
or there could be a fallback-to-guest.

Localization of Windows Account names was originally not a problem,
since the canonical representation (and the representation that
is computationally processed is the SID and not the account name.

Kerberos natively used name-based authentication, and a consistent
and reliable mapping between case-insensitive and possibly localized
account names and case-sensitive canonical Kerberos principal names
is a challenge that is still being worked on.

-Martin