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

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 05 Dec 2008 02:00:14 -0500

Two months ago (on Oct 1, 2008), I asked...

> Does anyone want to disagree with my assertion that we have reached
> consensus on these points?

There have been no responses, so I conclude that no one has disagreed. 
This point is now the only issue for anonymous that is not marked RESOLVED, 
because the current document does not reflect the consensus described 
above.  To resolve the issue, I believe the following changes are necessary 
(preceding each with corresponding quoted text from my Oct 1 message):

> There appears to be consensus that gss_display_name on a fully-anonymous
> name should return GSS_C_NT_ANONYMOUS with a display string constructed
> in  the same way as for GSS_KRB5_NT_PRINCIPAL; that is, it will look
> something  like "WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS".

At the end of the first paragraph of section 6, add the following or 
something similar:

      In addition, this syntax must be used along with the name type
      GSS_C_NT_ANONYMOUS for displaying and exporting the anonymous
      principal with the anonymous realm.

> There appears to be consensus that gss_display_name should work this way
> both for names resulting from gss_accept_context and for those resulting
> from import of an anonymous name.

I don't believe any change is needed to reflect this, as there is currently 
no text suggesting different behavior for these cases.

> There appears to be rough consensus that Kerberos GSS-API mechanism
> implementations _not_ be permitted to return a "localized" display name
> string instead of the one described above.
>
> It seems to be the sense of the group that strings returned by
> gss_display_name, while nominally intended for presentation, are in fact
> actually used as identifiers both by code and by users in ways that would
> be compromised if mechanism implementations were to localize them or in
> some other way use implementation-specific values.

I don't believe any change is needed to reflect these, aside from that 
described above.  With text requiring a particular display syntax, anything 
else would clearly be noncompliant.

> It seems to be the sense of the group that it would be acceptable for
> GSS-API applications to present anonymous principals and contexts to the
> user in whatever way makes the most sense for the application and user,
> which may include a localized presentation.

I don't think any text is required for this, but if the group feels it is 
important to call out, a paragraph could be added after the first paragraph 
of section 6 indicating that GSS-API applications may wish to present 
GSS_C_NT_ANONYMOUS credentials to users in some special way, rather than 
simply by printing the display string.

Larry, please make these updates and submit a new version so we can begin a 
final WGLC.  In addition, you should update the boilerplate to reflect the 
adoption of RFC4748, and you'll need to fix this problem that id-nits found:

  == The page length should not exceed 58 lines per page, but there was 2
     longer pages, the longest (page 15) being 66 lines

I will begin a WGLC as soon as the updated document appears in the I-D 
repository.

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

---

From: Sam Hartman <[email-masked]>
Date: Fri, 05 Dec 2008 07:17:52 -0500

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> Two months ago (on Oct 1, 2008), I asked...

    Jeffrey>      In addition, this syntax must be used along with the
    Jeffrey> name type GSS_C_NT_ANONYMOUS for displaying and exporting
    Jeffrey> the anonymous principal with the anonymous realm.

I'm not questioning your reading of the WG's consensus as I agree that
you have accurately judged consensus.  However I'm confused by the
implications of the above text.

In particular, I thought export names had an OID not a name type.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Martin Rex <[email-masked]>
Date: Fri, 5 Dec 2008 16:02:53 +0100 (MET)

> In particular, I thought export names had an OID not a name type.

It is actually an interesting question how an "anonymous name"
should be represented as "exported binary canonical name".

As I mentioned before, the concept of anonymous authentication and
anonymous names came late into the GSS-API v2 game and without
implementation experience, so they're somewhat underspecified.
So one must make logical guesses at various places where the
spec is lacking clear guidance in order to make things fit into
the big picture.

An exported name itself is always of type GSS_C_NT_EXPORTED_NAME.

The (binary) representation of an exported name comes with a standardized
framing, and that framing carries an OID.

The spec currently says that this OID in the generic framing of
a binary exported name is a mechanism OID, but there is no strong
requirement that it really be a mechanism OID -- what really counts
are the two characteristics that this OID is supposed to provide:

  - prevent accidental collisions of exported names from
    different gssapi mechanisms (or namespaces).

  - allow gss_import_name() to recognize and parse compatible/supported
    exported binary canonical names when they're re-imported and report
    a distinct error when being faced with an exported name from
    an unsupported/incompatible gssapi mechanism (or namespace).

In order for this to work, the spec or implementation referenced
by the OID in the generic framing must define the exact semantics
and representation of names in canonical form.

ack to the original (set of) question(s):

 - can anonymous names be exported in binary canonical form for
   storage in an ACL?

 - if yes, how are they represented?

If you look at the specification of the (only) GSS-API v1 call
that can be used for ACL checking: "gss_compare_name()", it is
actually defined in a funny way (I didn't do it):

      Allows callers to compare two internal name representations to
      determine whether they refer to the same entity.
(!)                                                     If either name
(!)   presented to GSS_Compare_name() denotes an anonymous principal,
(!)   GSS_Compare_name() shall indicate FALSE. 

The definition of "gss_export_name()" does not exhibit a similar
handicap.  It is entirely silent on anonymous names.  Although
the answer from gss_compare_name() is correct in a philosphical
fashion when both names passed to gss_compare_name() denote
anonymous pricinpals, this answer is somewhat unusable for ACL
checking.

We would need a standardized/canonical definition of an exported
binary canonical name in the high-level GSS-API spec in order to
make anonymous names (those carrying the GSS_C_NT_ANONYMOUS_NAME)
suitable for gss_export_name(), a representation that is the same
across all existing and future gssapi mechanisms in order to make
it fit the specified characteristics of gss_export_name().

I can not think of a way to define partial anonymous names in a
generic/portable (i.e. mechanism-independent) fashion.  It's up
to individual gssapi mechanism whether partial-anonymous names
exists as well as their exact syntax and semantics.
Partial anonymous names will have to use a mechanism-specific
nametype, i.e. one that is defined in the mechanism spec rather
than one from the gssapi spec(s) rfc2743(2744).  Sharing the
nametype with regular names should be OK, having a distinct
mechanism specific nametype for partial anonymous names should
also be OK.

Depending on the processing rules defined by the mechanism,
distinct nametypes might make it easier for gssapi callers to
work with partial anonymous names, it might reduce or obviate
the need to parse or mess around with the printale representation
when doing fancy things (like acquiring a credential for a
specific partial anonymous name).

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Fri, 05 Dec 2008 10:52:06 -0500

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

    Martin> We would need a standardized/canonical definition of an
    Martin> exported binary canonical name in the high-level GSS-API
    Martin> spec in order to make anonymous names (those carrying the
    Martin> GSS_C_NT_ANONYMOUS_NAME) suitable for gss_export_name(), a
    Martin> representation that is the same across all existing and
    Martin> future gssapi mechanisms in order to make it fit the
    Martin> specified characteristics of gss_export_name().

What would break if we exported a mechanism-specific form of an anonymous name?

As I understand it:

* It would make it harder for us to do something at the high-level spec later

* It would mean that a portable application could not tell from an exported name whether it was anonymous.

* It might increase the probability that a portable application would make an error and grant anonymous access in an unintended manner.

* It might increase the probability that a portable application would  assume that two sessions both from anonymous principals referred to the same user for auditing and object ownership  purposes.

Am I missing anything?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 05 Dec 2008 11:09:36 -0500

> should be represented as "exported binary canonical name".

Yes; in fact, it's a very interesting question, which you've done an 
exellent job of explaining.  Thank you.

> anonymous pricinpals, this answer is somewhat unusable for ACL

I think the intent here is that applications which are not aware of 
anonymous names not be fooled into thinking that two names describe the 
same entity when in fact no such thing has been proven.  You wouldn't want 
to accidentally get an anonymous name onto an anonymous-unaware 
application's ACL and suddenly have it admit anyone and everyone.

> it fit the specified characteristics of gss_export_name().

You are correct.  In particular, if we want exported anonymous names to 
compare equally, then each mechanism cannot define its own export syntax 
for them.  If we don't want exported anonymous names to compare equally, 
then we probably need to prohibit exporting them at all.  I'm not sure 
which we should do, but it seems clear that exporting anonymous principal 
names using the Kerberos mechansim OID and GSS_KRB5_NT_PRINCIPAL_NAME 
syntax is not the right answer.

At this point, I still believe we had consensus at the time of my original 
post, but I suspect that consensus may have been based on a significant 
misunderstanding of the requirements.  I'm still thinking about how best to 
proceed, and am open to suggestions.

> mechanism specific nametype for partial anonymous names should

That's actually not an issue here; the present document already describes 
how to handle partially-anonymous Kerberos principal names, by exporting 
them using the same syntax as for non-anonymous names.

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Fri, 5 Dec 2008 17:51:23 +0100 (MET)

> application's ACL and suddenly have it admit anyone and everyone.

My criticism about gss_compare_name() was intended only for the
"both names denote anonymous" case.  The behaviour for the
"only one of the names denoted anyomous" is fine.

It is not possible to have the calls gss_compare_name() or
gss_export_name() perform some kind of "wildcard matching",
because it is not clear which name is from an ACL and which
from an authentication.

Personally, I don't like any kind of "fallback to something" 
(e.g. fallback to guest).  I very much prefer an ACL entry
"<any-authenticated-user>:permissions" instead (this is not
equivalent!).  GSS-API itself doesn't provide and kind of
grouping (and fallback-to-someoneelse is a local matter).

Any gssapi callers that have rolled their own notion of
"<any-authenticated-user>:permissions" in their ACLs and
that are not watching out for (absenc of )the GSS_C_ANON_FLAG
are going to be surprised.  So maybe gssapi mechanisms should
provide a local means to "enable/disable" support for anonymous
on the server side and maybe default for off in order to not
introduce security problems into an installed base (that
is without support for anonymous authentication today).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 5 Dec 2008 18:01:43 +0100 (MET)

> * It might increase the probability that a portable application would  assume that two sessions both from anonymous principals referred to the same user for auditing and object ownership  purposes.

It (only) doesn't scale in the multi-mechanism direction,
As long as you're single-mech, you probably will not notice.

As soon as you start adding other mechanism (with seperate namespaces),
you would have to add further "anonymous" ACL entries, and then when
you want to change the anomous ACL entry, you will have to locate
and change all of them.

gss_export_name() will create an exported binary canonical name,
and for the notion of a (fully) anonymous name, it should either
create one (and just one) or refuse to do it.  IMHO.

-Martin