Subject: [Ietf-krb-wg] please cast your vote: do we need a standard way to invoke the partial anonymous name in Kerberos?

From: Larry Zhu <[email-masked]>
Date: Wed, 8 Oct 2008 17:58:16 -0700

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 <[email-masked]>
  >>    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?

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

  > OK, now I understand [proposes text]

  [[ Lots more discussion on this and A023 ]]

  <jhutz> proposes resolution

  [[ Asof 1-Oct-2008, still no resolution on the question of whether
  [[ to specify a standardized means of requesting partially-anonymous
  [[ credentials and contexts or leave it up to implementations.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 09 Oct 2008 06:57:07 -0400

--On Wednesday, October 08, 2008 05:58:16 PM -0700 Larry Zhu 
<[email-masked]> 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

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 09 Oct 2008 14:21:51 -0400

> the comment Larry just made.

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@<REALM> form
(or whatever is agreed to)?

Jeffrey Altman

---

From: Larry Zhu <[email-masked]>
Date: Thu, 9 Oct 2008 11:29:09 -0700

> 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@<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@" to invoke the partial anonymous name. Even with that if I want to supply username=lzhu@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@" or desired_name="lzhu@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: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Altman
Sent: Thursday, October 09, 2008 11:22 AM
To: [email-masked]
Subject: Re: [Ietf-krb-wg] please cast your vote: do we need a standard way to invoke the partial anonymous name in Kerberos?

Jeffrey Hutzelman 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.
>
> 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

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

Jeffrey Altman

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 09 Oct 2008 14:37:54 -0400

Larry:

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

Jeffrey Altman

---

From: Larry Zhu <[email-masked]>
Date: Thu, 9 Oct 2008 19:26:37 -0700

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.
 
More specifically if I want to use partial anonymous credentials for my credentials associated with my lzhu@ntdev account, it does not seem expressible.

> Date: Thu, 9 Oct 2008 14:37:54 -0400> From: [email-masked]> To: [email-masked]> CC: [email-masked]> Subject: Re: [Ietf-krb-wg] 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@<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@" to invoke the partial anonymous name. Even with that if I want to supply username=lzhu@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@" or desired_name="lzhu@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: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Altman> > Sent: Thursday, October 09, 2008 11:22 AM> > To: [email-masked]> > Subject: Re: [Ietf-krb-wg] 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> >> <[email-masked]> 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@<REALM> form (or whatever is agreed to)?> >> > Jeffrey Altman
_________________________________________________________________
Want to do more with Windows Live? Learn “10 hidden secrets” from Jamie.
http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008

---

From: Martin Rex <[email-masked]>
Date: Fri, 10 Oct 2008 18:32:31 +0200 (MEST)

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@REALM1 and userB@REALM1 using distinct
Kerberos passwords want to acquire an anonymous credential
WELLKNOWN/ANONYMOUS@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@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@NTDEV or lzhu@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
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Martin Rex <[email-masked]>
Date: Fri, 10 Oct 2008 18:47:51 +0200 (MEST)

Jeffrey Altman wrote:
>  [snipped discussion of credential password prompting]  
> 

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

---

From: Larry Zhu <[email-masked]>
Date: Fri, 10 Oct 2008 22:00:38 -0700

Martin Rex wrote:> If two distinct principals userA@REALM1 and userB@REALM1 using distinct> Kerberos passwords want to acquire an anonymous credential> WELLKNOWN/ANONYMOUS@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@REALM1". Should we use "WELLKNOWN/ANONYMOUS\userA@REALM1" or "WELLKNOWN/ANONYMOUS\userB@REALM1" to name these credentials objects in your example? This looks ugly but seems to work. If the working group wants a way to name the credentials objects with the partial anonymous name, I can propose text to capture this proposal. Otherwise, we can leave the API issue alone for now. --larry 

> From: [email-masked]> Subject: Re: [Ietf-krb-wg] please cast your vote: do we need a standard way> To: [email-masked]> Date: Fri, 10 Oct 2008 18:32:31 +0200> CC: [email-masked]; [email-masked]; [email-masked]> > > 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@REALM1 and userB@REALM1 using distinct> Kerberos passwords want to acquire an anonymous credential> WELLKNOWN/ANONYMOUS@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@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@NTDEV or lzhu@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.
_________________________________________________________________
See how Windows Mobile brings your life together—at home, work, or on the go.
http://clk.atdmt.com/MRT/go/msnnkwxp1020093182mrt/direct/01/

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 11 Oct 2008 10:09:24 -0400

--On Friday, October 10, 2008 10:00:38 PM -0700 Larry Zhu 
<[email-masked]> wrote:

> Martin Rex wrote:> If two distinct principals userA@REALM1 and
> userB@REALM1 using distinct> Kerberos passwords want to acquire an
> anonymous credential> WELLKNOWN/ANONYMOUS@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@REALM1". Should we use
> "WELLKNOWN/ANONYMOUS\userA@REALM1" or "WELLKNOWN/ANONYMOUS\userB@REALM1"
> to name these credentials objects in your example? This looks ugly but
> seems to work. If the working group wants a way to name the credentials
> objects with the partial anonymous name, I can propose text to capture
> this proposal. Otherwise, we can leave the API issue alone for now.
> --larry

The lack of any newlines in the above makes it difficult to read what you 
quoted from Martin, or to find where what Martin said stops and what you're 
saying starts.

IMHO, no, you should not use names such as you describe, because those 
names describe other, non-anonymous Kerberos principals.  I think if you 
wanted to capture both the actual principal name to use in authenticating 
to the KDC and the desire to use partially-anonymous credentials, you'd 
need to do so by defining a new name type or by using the "real" 
credentials along with a flag to GSS_Init_sec_context.

On the other hand, given that it is already relatively uncommon for 
initiators to specfy a name, perhaps it is sufficient to be able to request 
use of a partially-anonymous ticket obtained with what would otherwise be 
the default credentials?

-- Jeff

---

From: Jeffrey Altman <[email-masked]>
Date: Sat, 11 Oct 2008 10:44:35 -0400

There are two different scenarios:

1. The user already has one or more TGTs. 

what difference does it make which TGT is used to obtain the
partially-anonymous or fully-anonymous client principal within the ticket?

It can be left up to the implementation to figure it out. 

2. The user does not have a TGT or wants to use a known client principal
for which she does not have a TGT.

Now there are two issues.  How does the client obtain the TGT and the
second is how to specify that some degree of anonymity is desired. 

Larry can correct me if I am totally off the mark here but I believe the
user experience that is desired is that there is a database of known
client principals and keys and a standard user interface (CredMan?)
which is accessible to the Kerberos provider.   If the user requests a
service ticket and says she wants to use "myname@REALM1" as the identity
and there is a known key for that identity, everything just happens
beneath the covers.  If there is no known key, then the user is prompted
via CredMan to enter the key (password, smartcards, ...) and the
connection is made.

So the question becomes, how does the user specify that she wants to use
"myname@REALM1" and get back an anonymous or partially-anonymous TGT.  I
believe the answer is that it must be a flag that is specified as part
of the TGT acquisition OR it can be a reserved component in the
requested client principal name. 

Some possibilities might be (broken down to components):

    "myname" "WELLKNOWN:ANONYMOUS" @ "REALM"
    "WELLKNOWN:ANONYMOUS" "myname" @ "REALM"
    "ANONYMOUS:myname" @ "REALM"
   
    "myname" "WELLKNOWN:ANONYMOUS@REALM" @ "REALM"
    "WELLKNOWN:ANONYMOUS@REALM" "myname" @ "REALM"
    "ANONYMOUS@REALM:myname" @ "REALM"

At this point I'm not sure this is a GSS issue as much as a question of
how a Kerberos interface should standardize such a request.

Jeffrey Altman