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

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Jan 2009 16:03:49 -0500

--On Friday, December 05, 2008 11:09:36 AM -0500 Jeffrey Hutzelman 
<[email-masked]> wrote:

> --On Friday, December 05, 2008 04:02:53 PM +0100 Martin Rex
> <[email-masked]> wrote:
>
>
>> 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.
>
> 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.
>
>> 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().
>
> 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.

I've heard no responses here, and we need to come to a conclusion.
The difficulty here applies specifically to exported names, not to display 
names.  With respect to display names, I consider the issue to be closed. 
That discussion has little bearing on export names, which are binary blobs, 
not text strings, and so I consider the question of export names to still 
be completely open.  Now _this_ is the only remaining issue on anonymous.

I can see three possible courses of action here:

(1) Define a Kerberos-specific form for (fully) anonymous export names.
(2) Define a mechanism-independent form for anonymous export names.
(3) Prohibit export of anonymous names, leaving open the possibility
    that KITTEN will do (2) later.

I'd like to hear from the working group as to which option we should pursue.

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

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 9 Jan 2009 09:40:12 -0800

On Jan 7, 2009, at 1:03 PM, Jeffrey Hutzelman wrote:

>>> (!)                                                     If either  
>>> name

I'd vote for 3), but that's contingent on an absence of near-term  
consensus for 1) or 2).

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Tue, 13 Jan 2009 15:06:52 +0100 (MET)

> I'd like to hear from the working group as to which option we should pursue.

Without having deeply thought about it (lacking time...), a generic
(fully) anonymous name should probably be represented as an exported
name with the anonymous OID as the MECH_OID and an empty
representation (NAME_LEN==0) in the token described by
rfc2743 section 3.2.

The printable representation of (fully) anonymous principal seems to be
a fairly local matter (it could be subject to l10n), so I don't see
a point in trying to come up with a canonical representation for the
NAME part of the token and would propose to leave this field empty.
Recognition should be by the OID alone.  The structure of the mechanism
independent exported name token is exactly that the OID describes
the syntax&semantics of the inner part described by NAME&NAME_LEN. 

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Jan 2009 17:30:17 -0500

I've thought about the export name issues and have been unable to come
up with an opinion.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 27 Jan 2009 14:44:20 -0800

> I'd vote for 3), but that's contingent on an absence of near-term

Not seeing much consensus here.  I've got no problem with MR's  
proposal for 2), but absent some other vote of confidence, I revert to  
3) for the sake of moving forward.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Jan 2009 17:51:00 -0500

Martin's proposal for 2 seems sound. if we think 2 is the right
approach.