Re: Kerberos anonymity and GSS-API names

--On Tuesday, September 23, 2008 03:33:55 PM -0500 Nicolas Williams 
<Nicolas.Williams <at> sun.com> wrote:

> On Tue, Sep 23, 2008 at 04:28:35PM -0400, Sam Hartman wrote:
>> 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.
>
> 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().

It appears to me that we have consensus on some issues here...

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 <at> WELLKNOWN:ANONYMOUS".

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.

The state of anonymous

We have very nearly come to conclusion on anonymous.  I'm including an 
updated copy of the issue list below; a far as I know there is only one 
outstanding issue.  Once we have resolved that issue, we will begin a new 
WGLC on this document, and if/when that is resolved, I will ask Tim to do a 
new IETF last call.  Ideally, the new WGLC will be resolved before the next 
IETF meeting.

If anyone knows of issues which are not listed in the issue list or which 
they feel are _not_ resolved, please let me know so we can get them taken 
care of before the last call.

The remaining open issue I know of is A030, regarding the question of 
whether we should specify a standardized way of requesting 
partially-anonymous credentials and contexts or leave it up to 
implementations.  We seem to still be divided on that question.  I would 
like to ask anyone who has a position on this issue to restate whether you 
think we should or should not standardize this, and why.  I think this will 
help everyone to understand each other's positions, and it will certainly 
help me to make sure I know where we are on this.

-- Jeff

**********************************************************************
*** OUTSTANDING
**********************************************************************

* A030 Aug 22 Jeffrey Hutzelman <jhutz <at> cmu.edu>
  >>    while the use of an anonymous principal with
  >>    a non-anonymous realm by the initiator/client is based on
  >>    implementation specific local policy.

please cast your vote: do we need a standard way to invoke the partial anonymous name in Kerberos?

I spoke with Jeff earlier today and he is expecting cast-of-votes on the question if we need a standard way to
invoke the partial anonymous name in Kerberos. Please send in your comments.

This issue is captured as issue A030 provided for your convenience at the bottom of this email.

As an individual, I would like to vote "no" on the ground that the existing desired_name parameter (of
GSS_Acquire_name()) in the proposal seems too specific to the acceptor instead of the initiator.

--larry

p.s. issue A030:

* A030 Aug 22 Jeffrey Hutzelman <jhutz <at> cmu.edu>
  >>    while the use of an anonymous principal with
  >>    a non-anonymous realm by the initiator/client is based on
  >>    implementation specific local policy.
  >
  > What does this mean?
  > What behavior is this talking about?
  >
  > The phrase "implementation specific local policy" is unclear -- is the
  > behavior implementation-defined or is it controlled by policy?

   <at>  I am not sure if this is a rhetoric question but I answer it any
   <at>  way: this talks about how to invoke your GSS-API to use an anonymous
   <at>  principal with a non-anonymous realm  is left to the implementation
   <at>  because such kinds of names do not correspond to GSS_NT_ANONYMOUS.

  > OK, now I understand [proposes text]

Re: please cast your vote: do we need a standard way to invoke the partial anonymous name in Kerberos?

--On Wednesday, October 08, 2008 05:58:16 PM -0700 Larry Zhu 
<lzhu <at> windows.microsoft.com> wrote:

> I spoke with Jeff earlier today and he is expecting cast-of-votes on the
> question if we need a standard way to invoke the partial anonymous name
> in Kerberos. Please send in your comments.

That's not what I said.  We are not voting; we are attempting to reach 
consensus.  Thus, I'm not asking for votes.

What I _am_ asking for is for anyone with an interest in this issue to 
state a position, including reasoning.  I'm hoping this will provide enough 
fodder for a discussion leading to consensus, without which we cannot move 
the document forward.  So far, I have not had a single response, aside from 
the comment Larry just made.

-- Jeff
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

Re: please cast your vote: do we need a standard way to invoke the partial anonymous name in Kerberos?

Jeffrey Hutzelman wrote:
> --On Wednesday, October 08, 2008 05:58:16 PM -0700 Larry Zhu 
> <lzhu <at> windows.microsoft.com> wrote:
> 
>> I spoke with Jeff earlier today and he is expecting cast-of-votes on the
>> question if we need a standard way to invoke the partial anonymous name
>> in Kerberos. Please send in your comments.
> 
> That's not what I said.  We are not voting; we are attempting to reach 
> consensus.  Thus, I'm not asking for votes.
> 
> What I _am_ asking for is for anyone with an interest in this issue to 
> state a position, including reasoning.  I'm hoping this will provide enough 
> fodder for a discussion leading to consensus, without which we cannot move 
> the document forward.  So far, I have not had a single response, aside from 
> the comment Larry just made.
> 
> -- Jeff

If there is no standard way to ask for it, how would anyone ever use it?

Why can't the credential be requested using gss_acquire_cred()
specifying the desired name using the RESERVED:ANONYMOUS <at> <REALM> form
(or whatever is agreed to)?

Jeffrey Altman

_______________________________________________

Re: please cast your vote: do we need a standard way to invoke the partial anonymous name in Kerberos?

Jeffrey Altman wrote:
> If there is no standard way to ask for it, how would anyone ever use it?

There is no standard way to supply username+password today in GSS-API. I do not see why the partial
anonymous name is different than the full anonymous principal name. The partial anonymous name should be
considered as just a principal name.

>Why can't the credential be requested using gss_acquire_cred() specifying the desired name using the
RESERVED:ANONYMOUS <at> <REALM> form (or whatever is agreed to)?

That means that the client need to know the realm and there are shorter and longer forms of the realms. All
these seem to be just unnecessary complexity.

If you insist, how about setting the desired name to be just "RESERVED:ANONYMOUS <at> " to invoke the partial
anonymous name. Even with that if I want to supply username=lzhu <at> NTDEV, password=junk and assume I want
to use partial anonymous name for myself, I would run out my luck again because either I can say
desired_name="RESERVED:ANONYMOUS <at> " or desired_name="lzhu <at> NTDEV", but not both at the same time.

I am pushing back on standardizing the API here because I am afraid we will open a can of worms as I just
described above.

--larry

-----Original Message-----
From: ietf-krb-wg-bounces <at> lists.anl.gov [mailto:ietf-krb-wg-bounces <at> lists.anl.gov] On Behalf Of
Jeffrey Altman
Sent: Thursday, October 09, 2008 11:22 AM
To: ietf-krb-wg <at> anl.gov
Subject: Re: [Ietf-krb-wg] please cast your vote: do we need a standard way to invoke the partial anonymous
name in Kerberos?

Re: please cast your vote: do we need a standard way to invoke the partial anonymous name in Kerberos?

Larry:

When has GSSAPI ever been used to obtain a credential with a password?

Jeffrey Altman

Larry Zhu wrote:
> Jeffrey Altman wrote:
>> If there is no standard way to ask for it, how would anyone ever use it?
>
> There is no standard way to supply username+password today in GSS-API. I do not see why the partial
anonymous name is different than the full anonymous principal name. The partial anonymous name should be
considered as just a principal name.
>
>> Why can't the credential be requested using gss_acquire_cred() specifying the desired name using the
RESERVED:ANONYMOUS <at> <REALM> form (or whatever is agreed to)?
>
> That means that the client need to know the realm and there are shorter and longer forms of the realms. All
these seem to be just unnecessary complexity.
>
> If you insist, how about setting the desired name to be just "RESERVED:ANONYMOUS <at> " to invoke the partial
anonymous name. Even with that if I want to supply username=lzhu <at> NTDEV, password=junk and assume I want
to use partial anonymous name for myself, I would run out my luck again because either I can say
desired_name="RESERVED:ANONYMOUS <at> " or desired_name="lzhu <at> NTDEV", but not both at the same time.
>
> I am pushing back on standardizing the API here because I am afraid we will open a can of worms as I just
described above.
>
> --larry
>

Re: please cast your vote: do we need a standard way to invoke the partial anonymous name in Kerberos?

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

Re: please cast your vote: do we need a standard way

Larry Zhu wrote:
> 
> I spoke figuratively. Suppose I want to supply alternative
> credentials/keys (not the password), then I do not have a
> standard way to do that.

GSS-API standardizes _only_ a simple way of _anonymous_authentication_.

When using GSS-API, there is no standardized way to acquire credentials
by password, credentials can only be acquire by name, implying that
(pre-existing) credentials are merely accessed, not created.
Creation and destruction of credentials is a local matter.

A password for an anonymous credentials is IMHO a misconception.

If the underlying gssapi mechanism requires and explicit,
password-protected credential in order to create or obtain an
anonymous credential, then this ought not to be confused --
this is then no password for the anonymous credential.

If two distinct principals userA <at> REALM1 and userB <at> REALM1 using distinct
Kerberos passwords want to acquire an anonymous credential
WELLKNOWN/ANONYMOUS <at> REALM1, then I assume that each one would have
to supply his very own password (if any) in a non-standardized
fashion, rather than both supplying a (wellknown?!?) password
of the principal "WELLKNOWN/ANONYMOUS <at> REALM1".

The bottom line is: GSS-API does *NOT* define anonymous credentials
and so does neither standardize nor describe how to acquire them.
(btw. would SSPI prompt the user to enter the password for
 WELLKNOWN/ANONYMOUS <at> NTDEV or lzhu <at> NTDEV?)

Thinking about it, the recommended portable use of gssapi with
the standardized used of "anonymous authentication" is likely
to result in the partial-anonymous authentication, because
it means that gss_init_sec_context() is called with a NULL
credentials handle (meaning "use default credential"),
and requesting the anonymous authentication context attribute.

Although it sounds somewhat counter-intuitive -- one could argue
that a partially anonymous security context resulting from
the use of the default credential should actually be indicated
with the return of the GSS_C_ANONYMOUS_FLAG.

As was discussed, a fully-anonymous authentication with Kerberos
may require the use of an explict credential created via PKINIT,
and some yet unspecified means to acquire an explicit credentials
handle (gss_cred_id_t) to this credential in order to pass it
to gss_init_sec_context().  The only currently GSS-API standardized
way to acquire a credential handle to an existing credentials
(created in a implementation defined way) is by name, by mechanism
or a combination of both.

-Martin

PS: Larry, the quoted text in your last Email was concatenated into one
    super-long single line, all linefeeds removed (at least in the ASCII
    part that I'm using.
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

Re: please cast your vote: do we need a standard way

Jeffrey Altman wrote:
>  [snipped discussion of credential password prompting]  
> 
> If there is no standard way to ask for it, how would anyone ever use it?
> 
> Why can't the credential be requested using gss_acquire_cred()
> specifying the desired name using the RESERVED:ANONYMOUS <at> <REALM> form
> (or whatever is agreed to)?

Nitpicking on some details.

gss_acquire_cred() acquires a gssapi credentials handle (gss_cred_id_t)
to an existing credential.
When or how the underlying credential is created or obtained is a local
matter.

The standardized means that gss_acquire_cred() provides in order to
specify which (of potentially multiple available) credentials to
access are "name" and "mechnism OID". 

It is expected that names can be provided by "importing" a name
in the kerberos principal name syntax along with either a
kerberos principal name or a NULL nametype OID.

It is conceivable to pass to gss_import_name() an arbitrary
non-null printable name along with the anonymous nametype OID,
and if we specify anonymous authentication for the Kerberos GSS-API
mechanism, we should probalbly also specify what is going to happen
(or supposed to happen) if the resulting gss_name_t from
importing a name with the anonymous nametype OID is passed
to gss_acquire_cred().

-Martin

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg