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

From: Larry Zhu <[email-masked]>
Date: Thu, 14 Aug 2008 12:29:18 -0700

* A022 Apr 07 Ken Raeburn <raeburn at mit.edu>
  > First, the GSS-API concept of anonymous session establishment seems to
  > be that the client isn't authenticated at all.  In the WELLKNOWN/
  > ANONYMOUS at SOME-REALM case, *if* anonymous AS requests can only use WK/
  > A at WELLKNOWN:ANONYMOUS as the client name (see Sam's email), then we're
  > giving the server information about the identity of the client.  Maybe
  > not the client's full identity, but at least the realm name.  Should
  > it be treated as anonymous authentication at the GSS-API layer
  > (GSS_C_ANON_FLAG, NT-ANONYMOUS), or not?  The text in krb-wg-anon does
  > imply that realm names may be included in NT-ANONYMOUS names, when
  > discussing the exported name format, but does this match the GSS-API
  > concept of anonymous security context establishment?

==============================

* A023 Apr 07 Ken Raeburn <raeburn at mit.edu>
  > Should importing an anonymous Kerberos principal name and calling
  > display_name get NT-ANONYMOUS back as the type, or should NT-ANONYMOUS
  > names only be generated by accept_sec_context?

Thanks Jeff and Nico for their recent posts on the list. Here is the proposed text based on list discussions.

5.  GSS-API Implementation Notes

   GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to
   represent the anonymous identity.  In addition, Section 2.1.1 of
   [RFC1964] defines the single string representation of a Kerberos
   principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME.  The
   anonymous principal with the anonymous realm corresponds to the GSS-
   API anonymous principal.  A principal with the anonymous principal
   name and a non-anonymous realm is an authenticated principal, hence
   such a principal does not correspond to the anonymous principal in
   GSS-API with the GSS_C_NT_ANONYMOUS name type, and this principal's
   corresponding name component within the exportable name as defined in
   Section 2.1.3 of [RFC1964] MUST signify the realm name according to
   Section 2.1.1 of [RFC1964].

   At the GSS-API [RFC2743] level, the use of an anonymous principal
   with the anonymous realm by the initiator/client requires the
   initiator/client to assert the "anonymous" flag when calling
   GSS_Init_Sec_Context(); while the use of an anonymous principal with
   a non-anonymous realm by the initiator/client is based on
   implementation specific local policy.

   GSS-API does not know or define "anonymous credentials", so the
   (printable) name of the anonymous principal will rarely be used by or
   relevant for the initiator/client.  The printable name is relevant
   for the acceptor/server when performing an authorization decision
   based on the initiator name that is returned from the acceptor side
   upon the successful security context establishment.

   A GSS-API initiator MUST carefully check the resulting context
   attributes from the initial call to GSS_Init_Sec_Context() when
   requesting anonymity, because (as in the GSS-API tradition and for
   backwards compatibility) anonymity is just another optional context
   attribute.  It could be that the mechanism doesn't recognize the
   attribute at all or that anonymity is not available for some other
   reasons -- and in that case the initiator MUST NOT send the initial
   security context token to the acceptor, because it will likely reveal
   the initiators identity to the acceptor, something that can rarely be
   "un-done".

   Portable initiators are RECOMMENDED to use default credentials
   whenever possible, and request anonymity only through the input
   anon_req_flag [RFC2743] to GSS_Init_Sec_Context().

Please comment on this if the text is not sufficient or unclear.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 22 Aug 2008 16:22:38 -0400

>    while the use of an anonymous principal with

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?

Your proposed changes appear to answer the question asked in A022 related 
to whether an anonymous@REALM ticket can be treated as anonymous, but does 
not answer the question asked in A023 regarding the behavior of 
GSS_display_name.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 22 Aug 2008 16:23:26 -0400

> behavior implementation-defined or is it controlled by policy?

I am assigning issue number A030 to these questions.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 22 Aug 2008 15:34:20 -0500

> not answer the question asked in A023 regarding the behavior of 

Does that matter?  IIRC RFC2743 didn't specify a display form for
GSS_C_NT_ANONYMOUS principals (RFC2744 gives an example of how one might
choose to display them).  Also, just because you imported as
GSS_C_NT_ANONYMOUS does not mean that the name must display as such (the
same is true for other name types).
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 22 Aug 2008 16:42:29 -0400

--On Friday, August 22, 2008 03:34:20 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> Your proposed changes appear to answer the question asked in A022
>> related  to whether an anonymous@REALM ticket can be treated as
>> anonymous, but does  not answer the question asked in A023 regarding the
>> behavior of  GSS_display_name.
>

Well, the question was asked, twice (see also A016), so I assume that the 
existing specification is not sufficiently clear on how GSS_display_name 
should behave with respect to anonymous Kerberos principal names.  I 
believe the comments must be addressed; if the document editor, commenters, 
and WG agree there is no need for further change, that is fine.

-- Jeff

---

From: Larry Zhu <[email-masked]>
Date: Fri, 22 Aug 2008 13:44:56 -0700

+1. this document should not need to specify what is the display name and it can leave it to implementations.

---

From: Larry Zhu <[email-masked]>
Date: Fri, 22 Aug 2008 13:47:32 -0700

Jeffrey Hutzelman wrote:
> Your proposed changes appear to answer the question asked in A022 related to whether an >
> anonymous@REALM ticket can be treated as anonymous, but does not answer the question asked >
in A023 regarding the behavior of GSS_display_name.

What is the display_name() returns is left to implementations. No further change is needed for this IMO.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Hutzelman
Sent: Friday, August 22, 2008 1:23 PM
To: Larry Zhu; [email-masked]
Cc: [email-masked]; Williams; Ken Raeburn; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ietf-krb-wg] Kerberos anonymity and GSS-API names

What does this mean?

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 22 Aug 2008 15:49:05 -0500

> and WG agree there is no need for further change, that is fine.

I'm not sure that anything needs to be done.

Quite clearly the display name form for anonymous names is
implementation-specific as far as RFC2743/2744 are concerned, though one
obvious thing to do is to actually display the actual krb5 principal
name.

That said, I certainly don't mind this doc actually specifying a display
name form for krb5 anon names.

Nico
--

---

From: Larry Zhu <[email-masked]>
Date: Fri, 22 Aug 2008 13:50:19 -0700

> What behavior is this talking about?

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.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Hutzelman
Sent: Friday, August 22, 2008 1:23 PM
To: Larry Zhu; [email-masked]
Cc: [email-masked]; Williams; Ken Raeburn; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ietf-krb-wg] Kerberos anonymity and GSS-API names

What does this mean?

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 22 Aug 2008 16:52:39 -0400

--On Friday, August 22, 2008 01:47:32 PM -0700 Larry Zhu 
<[email-masked]> wrote:

>> related to whether an > anonymous@REALM ticket can be treated as
>> anonymous, but does not answer the question asked >

Ken?  Sam?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 22 Aug 2008 17:02:15 -0400

--On Friday, August 22, 2008 01:50:19 PM -0700 Larry Zhu 
<[email-masked]> wrote:

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

Ah, OK.  What you're trying to say is that you can ask your implementation 
to use a fully anonymous ticket by setting the anonymous flag, but that the 
way to request use of a partially-anonymous ticket is implementation 
specific, if it exists at all.

In that case, I would suggest rewriting that whole paragraph as follows:

	At the GSS-API [RFC2743] level, an initiator/client requests the
	use of an anonymous principal with the anonymous realm by asserting
	the "anonymous" flag when calling GSS_Init_Sec_Context().  The
	GSS-API implementation MAY provide an implementation-specific
	interface for requesting the use of an anonymous principal with a
	non-anonymous realm.

Two paragraphs later, the initiator is admonished to check the context 
attributes, since requesting an anonymous context doesn't mean you got one. 
It might be worth noting that if fully anonymous credentials could not be 
obtained, an implementation might choose to return a non-anonymous context 
using a partially-anonymous principal name.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Fri, 22 Aug 2008 17:11:26 -0400

I'm concerned that we do not want to specify too much here: I don't think we fully understand what GSS-API should do in all these cases.
I think Larry's proposal (possibly with implementation defined replacing local policy) is a good compromise and is about as good as I think we can get now.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Fri, 22 Aug 2008 14:15:33 -0700

>        interface for requesting the use of an anonymous principal with a

I feel this is too restrictive by requiring an interface change. How about

   <t>At the GSS-API <xref target="RFC2743"/> level, the use of an anonymous principal
   with the anonymous realm by the initiator/client requires the
   initiator/client to assert the "anonymous" flag when calling
   GSS_Init_Sec_Context(); while the use of an anonymous principal with
   a non-anonymous realm by the initiator/client is based on
   implementation specific local policy. For example, the GSS-API implementation MAY provide an implementation-specific
   interface for requesting the use of an anonymous principal with a
   non-anonymous realm.</t>

This way it does not preclude implementations from invoking the non-anonymous name *without* changing the interface, via a policy setting.

What do you think?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Hutzelman
Sent: Friday, August 22, 2008 2:02 PM
To: Larry Zhu; [email-masked]
Cc: [email-masked]; Williams; Ken Raeburn; [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, 22 Aug 2008 17:33:31 -0400

--On Friday, August 22, 2008 02:15:33 PM -0700 Larry Zhu 
<[email-masked]> wrote:

>>        use of an anonymous principal with the anonymous realm by
>>        asserting the "anonymous" flag when calling
>>        GSS_Init_Sec_Context().  The GSS-API implementation MAY provide
>>        an implementation-specific interface for requesting the use of an
>>        anonymous principal with a non-anonymous realm.
>
>    <t>At the GSS-API <xref target="RFC2743"/> level, the use of an
> anonymous principal    with the anonymous realm by the initiator/client
> requires the
>    implementation specific local policy. For example, the GSS-API
> implementation MAY provide an implementation-specific    interface for
> requesting the use of an anonymous principal with a    non-anonymous
> realm.</t>

First, note that I rewrote the whole paragraph deliberately because the 
phrasing "the use of ... requires..." suggests that some external factor is 
reuqiring the initiator to behave in a specific way, when what you are 
actually specifying is how the initiator asks the GSS mechanism to behave 
in a specific way.  This is an even greater problem with the next sentence, 
where "the use of... is based on" doesn't tell me anything, and perhaps 
implies that there is some policy that decides whether the initiator should 
use such a principal.  This phrasing was a significant part of why I didn't 
understand what the existing text was trying to say, and so I proposed 
phrasing that I believe more clearly says what is intended.  Adding a "for 
example" doesn't really resolve this part of the problem.

Second, "implementation specific local policy" does not mean what you are 
trying to say.  "Local policy" is something defined by the system 
administrator, not by the implementation.  What you are trying to say, if I 
understand, is that there may be an implementation-specific way to do this, 
not that the administrator of every client machine gets to decide what the 
way is to do this.  Don't use the words "local policy"; they don't apply 
here.

Thirdly, I think perhaps we disagree on the meaning of "interface".  An 
implementation-defined interface is not necessarily a new function call; it 
might take the form of a particular name type, or an implementation-defined 
flag (does GSS-API allow that?), or I-don't-know-what.  Can you clarify 
what an implementation might do to allow this that would not constitute an 
interface?

Perhaps we can use a different word here, like "an implementation-specific 
means".

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 22 Aug 2008 16:33:46 -0500

> 	interface for requesting the use of an anonymous principal with a

That's what the GSS_C_NO_OID and GSS_KRB5_NT_PRINCIPAL_NAME name type
OIDs are for!

> using a partially-anonymous principal name.

What's a "non-anonymous context"?  I suppose GSS_Init_sec_context()
could not set the anon ret flag.

But, yes, without that flag OR a standard display name form there's no
way for the initiator to tell whether it got a partially anonymous
ticket.

Perhaps we need a new flag?  But I think we don't really, and simpler is
better.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 22 Aug 2008 17:41:59 -0400

> That's what the GSS_C_NO_OID and GSS_KRB5_NT_PRINCIPAL_NAME name type

Are you suggesting that we should simply specify that an initiator wishing 
to use a partially-anonymous ticket does so by using 
GSS_KRB5_NT_PRINCIPAL_NAME with a partially-anonymous principal name, and 
get rid of the "implementation-specific" bit entirely?  I admit there is 
some attraction to having a defined way to do this.

>> attributes, since requesting an anonymous context doesn't mean you got
>> one.  It might be worth noting that if fully anonymous credentials could
>> not be  obtained, an implementation might choose to return a
>> non-anonymous context  using a partially-anonymous principal name.
>

Yes; that's what I meant.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 22 Aug 2008 16:46:03 -0500

> That's what the GSS_C_NO_OID and GSS_KRB5_NT_PRINCIPAL_NAME name type

I.e., if the client wants to use an anonymous principal with a
non-anonymous realm then it should format the krb5 principal name using
RFC1964 syntax, import it using GSS_KRB5_NT_PRINCIPAL_NAME or
GSS_C_NO_OID, and use it to acquire a credential handle.

> Perhaps we need a new flag?  But I think we don't really, and simpler is

I should expand on this.

So we have an initiator passing in anon_req_flag to
GSS_Init_sec_context() but getting back anon_state == FALSE if it got a
partially anonymous ticket.

Q:  So how can the initiator discover whether it had a partially
    anonymous ticket or a ticket that was completely not anonymous?

A1: A portable initiator shouldn't care :)

A2: The initiator could GSS_Inquire_sec_context() to get its name,
    GSS_Display_name() it, and parse it (or check the name type?).

    But this can't be done without a standard display syntax or
    krb5-specific name type denoting "partially anonymous."

    Alternatively, a new ret_flag indicating partial anonymity would
    solve this problem.  But that seems very krb5-specific.  Or can
    partial anonymity be provided by other sorts of mechanisms?  (Well,
    I suppose one could construct a ticketing-like mechanism with SAML
    to prove the point...)

I think I'm happy with A1 (I'll need a juicy steak to go with it;
<drum roll>) and don't care about A2.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 22 Aug 2008 16:47:00 -0500

> some attraction to having a defined way to do this.

I am.  But keep in mind, I'd expect GSS_KRB5_NT_PRINCIPAL_NAME to just
work with these names.

Nico

---

From: Sam Hartman <[email-masked]>
Date: Fri, 22 Aug 2008 17:57:25 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Fri, Aug 22, 2008 at 05:41:59PM -0400, Jeffrey
    Nicolas> Hutzelman wrote:
    >> Are you suggesting that we should simply specify that an
    >> initiator wishing to use a partially-anonymous ticket does so
    >> by using GSS_KRB5_NT_PRINCIPAL_NAME with a partially-anonymous
    >> principal name, and get rid of the "implementation-specific"
    >> bit entirely?  I admit there is some attraction to having a
    >> defined way to do this.

    Nicolas> I am.  But keep in mind, I'd expect
    Nicolas> GSS_KRB5_NT_PRINCIPAL_NAME to just work with these names.

I'm unconvinced this is the right answer.  In particular I'm
unconvinced you want requesting a particular principal name to set a
KDC option.  For that reason I prefer not to go into this detail at
this time.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 22 Aug 2008 17:58:04 -0400

--On Friday, August 22, 2008 04:47:00 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> Are you suggesting that we should simply specify that an initiator
>> wishing  to use a partially-anonymous ticket does so by using
>> GSS_KRB5_NT_PRINCIPAL_NAME with a partially-anonymous principal name,
>> and  get rid of the "implementation-specific" bit entirely?  I admit
>> there is  some attraction to having a defined way to do this.
>

Actually, so would I.  Can we just say that, instead of making something be 
implementation-specific when there is both an obvious way to standardize it 
and an portability benefit to doing so?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 22 Aug 2008 16:59:10 -0500

> KDC option.  For that reason I prefer not to go into this detail at

You'd still have to use the anon_req_flag!  Also, I'm not sure how a
client could get such a ticket without setting the KDC option, but
whatever.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 22 Aug 2008 17:00:57 -0500

> and an portability benefit to doing so?

I'd be in favor of that.

---

From: Martin Rex <[email-masked]>
Date: Sat, 23 Aug 2008 00:17:46 +0200 (MEST)

Nicolas Williams wrote:
> Does that matter?

I (also) think it matters.

>
> IIRC RFC2743 didn't specify a display form for

It is correct that RFC-2743 does not specify one universal printable string
for visualizing the anonymous principal.  The reason that it does not
do that is that this can not be done in a "portable", i.e. mechanism
independent fashion.  PKI-based gssapi mechanisms that use X.509 certs
for authentication and use the subject distinguished names of the
certs to identify users might want to visualize differently from
the Kerberos mechanism, where something like a Kerberos principal
name syntax might be preferred.

A particular gssapi mechanism (spec) which defines the syntax for
the printable names, however, should also specify the representation
of the anonymous name(s) for all implementations of that mechanism
that support anonymity.  The printable name is primarily for
presentation to the user(s), and it would *NOT* be a good idea
if every implementation was using a different string to visualize
the anonymous name/identity/principal.

Since you're going to standardize the representation within
the Kerberos protocol, there shouldn't be a problem coming up
with an printable representation for gss_display_name() through
the same transformation that is applied to convert a Kerberos
principal name into a printable representation (I assume).

-Martin

---

From: Larry Zhu <[email-masked]>
Date: Fri, 22 Aug 2008 17:25:41 -0700

Jeffrey Hutzelman wrote:
> Second, "implementation specific local policy" does not mean what you are trying to say.  "Local policy" is something defined by the system administrator, not by the implementation.  What you
> are trying to say, if I understand, is that there may be an implementation-specific way to do this, not that the administrator of every client machine gets to decide what the way is to do >

> this.  Don't use the words "local policy"; they don't apply here.

I actually meant system policy set by administrators. The rest of differences seem self-explanatory.

I am fine with your proposed text, but I would like to replace the word "a implementation-specific interface" with " implementation-specific means".

   <t>At the GSS-API <xref target="RFC2743"/> level, an initiator/client requests the
use of an anonymous principal with the anonymous realm by asserting
the "anonymous" flag when calling GSS_Init_Sec_Context().  The
GSS-API implementation MAY provide implementation-specific
means for requesting the use of an anonymous principal with a
non-anonymous realm.</t>

I am not strongly against the word "interface" however.

--larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Hutzelman
Sent: Friday, August 22, 2008 2:34 PM
To: Larry Zhu; [email-masked]
Cc: [email-masked]; Williams; Ken Raeburn; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ietf-krb-wg] Kerberos anonymity and GSS-API names

-- Jeff

---

From: Larry Zhu <[email-masked]>
Date: Fri, 22 Aug 2008 17:46:20 -0700

RFC2743 says that you cannot rely on GSS_Acquire_cred() support for any name other than GSS_C_NO_NAME for the intiator.

   This routine is expected to be used primarily by context acceptors,
   since implementations are likely to provide mechanism-specific ways
   of obtaining GSS-API initiator credentials from the system login
   process.  Some implementations may therefore not support the
   acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials via
   GSS_Acquire_cred() for any name other than GSS_C_NO_NAME, or a name
   resulting from applying GSS_Inquire_context() to an active context,
   or a name resulting from applying GSS_Inquire_cred() against a
   credential handle corresponding to default behavior. It is important
   to recognize that the explicit name which is yielded by resolving a
   default reference may change over time, e.g., as a result of local
   credential element management operations outside GSS-API; once
   resolved, however, the value of such an explicit name will remain
   constant.

Hence I propose it is best to leave the details to implementations.

--larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]]
Sent: Friday, August 22, 2008 2:46 PM
To: Jeffrey Hutzelman; Larry Zhu; [email-masked]; [email-masked]; Ken Raeburn; [email-masked]; [email-masked]
Subject: Re: [Ietf-krb-wg] Kerberos anonymity and GSS-API names

I should expand on this.

Nico
--

---

From: Larry Zhu <[email-masked]>
Date: Fri, 22 Aug 2008 17:53:26 -0700

Jeffrey Hutzelman wrote:
> Two paragraphs later, the initiator is admonished to check the context attributes, since requesting an anonymous context doesn't mean you got one.
> It might be worth noting that if fully anonymous credentials could not be obtained, an implementation might choose to return a non-anonymous context using a partially-anonymous principal name.

Fhe full anonymous and partial anonymous should be considered different options to the apps. Given that we leave the partial-anonymous option (how to invoke and how to check) to implementations, it seems best to leave this out as well.

It seems to me if the app wants to full anonymous, it should get full anonymous or fail. It seems overwhelmingly complex to accept partial anonymous if full-anonymous is not available upon request. At least we so far do not have such a use case for that.

--larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Hutzelman
Sent: Friday, August 22, 2008 2:02 PM
To: Larry Zhu; [email-masked]
Cc: [email-masked]; Williams; Ken Raeburn; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ietf-krb-wg] Kerberos anonymity and GSS-API names

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 23 Aug 2008 11:19:55 -0500

> Hence I propose it is best to leave the details to implementations.

I think you misread the above.

The above says that support fore desired_name != GSS_C_NO_NAME is
OPTIONAL, not that how it works is implementation specific.

Nico

---

From: Larry Zhu <[email-masked]>
Date: Sat, 23 Aug 2008 10:11:40 -0700

>OPTIONAL, not that how it works is implementation specific.

I acutually wanted to point out that implementations do not support desired_name != NO_NAME for the initiators, not that the implementations might be done or behave differently.

Was the proposal to invoke anonymous@realm to supply that name to the desried_name parameter of GSS_Acquire_cred()? It might just boil down that portable GSS-API apps cannot rely on the desired_name support.

Thank you for your contribution, it helps us make progress here and it helps us move the document forward.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Nicolas Williams [[email-masked]]
Sent: Saturday, August 23, 2008 9:19 AM
To: Larry Zhu
Cc: [email-masked]; [email-masked]; Ken Raeburn; [email-masked]; [email-masked]; Jeffrey Hutzelman
Subject: Re: [Ietf-krb-wg] Kerberos anonymity and GSS-API names

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 23 Aug 2008 15:30:51 -0400

--On Friday, August 22, 2008 05:25:41 PM -0700 Larry Zhu 
<[email-masked]> wrote:

> Jeffrey Hutzelman wrote:
>> Second, "implementation specific local policy" does not mean what you
>> are trying to say.  "Local policy" is something defined by the system
>> administrator, not by the implementation.  What you are trying to say,
>> if I understand, is that there may be an implementation-specific way to
>> do this, not that the administrator of every client machine gets to
>> decide what the way is to do >
>

I don't think we want policy to control what one piece of software (a 
GSS-API application) must do to get another piece of software (a GSS-API 
mechanism) to do the right thing.

> I am fine with your proposed text, but I would like to replace the word
> "a implementation-specific interface" with " implementation-specific
> means".

That's fine with me.  However, let's wait and see what comes of the 
question of whether we can/should just specify this instead of leaving it 
up to the implementation, which is under discussion in another subthread.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 23 Aug 2008 15:37:59 -0400

--On Saturday, August 23, 2008 10:11:40 AM -0700 Larry Zhu 
<[email-masked]> wrote:

> I acutually wanted to point out that implementations do not support
> desired_name != NO_NAME for the initiators, not that the implementations
> might be done or behave differently.
>
> Was the proposal to invoke anonymous@realm to supply that name to the
> desried_name parameter of GSS_Acquire_cred()? It might just boil down
> that portable GSS-API apps cannot rely on the desired_name support.

Well, portable apps cannot rely on Kerberos partial anonymity, either.
If the specification says that Kerberos mechanism implementations which 
support partial anonymity do so by supporting GSS_Acquire_cred to get 
GSS_C_INITIATE credentials with a GSS_KRB5_NT_PRINCIPAL_NAME of the form 
"WELLKNOWN/ANONYMOUS@realm", then apps will be able to depend on mechanisms 
which support partial anonymity also supporting those arguments to 
GSS_Acquire_cred.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 24 Aug 2008 21:34:29 -0500

On Sat, Aug 23, 2008 at 10:11:40AM -0700, Larry Zhu wrote:
> desired_name != NO_NAME for the initiators, not that the
> implementations might be done or behave differently.
> 

The proposal would be to say that existing RFC1964 name syntax should be
used for importing partial anon names and for displaying them (and
exporting them).
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 24 Aug 2008 21:36:46 -0500

> which support partial anonymity also supporting those arguments to 

Really?  I'd think that you'd need a new generic name type.

GSS_C_NT_PARTIALLY_ANONYMOUS, with anon@<realm> query syntax.

Nico

---

From: Larry Zhu <[email-masked]>
Date: Sun, 24 Aug 2008 20:45:46 -0700

> used for importing partial anon names and for displaying them (and

+1. Is it sufficient to add the following text?

   The [RFC1964] name
   syntax for GSS_KRB5_NT_PRINCIPAL_NAME MUST be used for importing the
   anonymous principal name with a non-anonymous realm name and for
   displaying and exporting these names.

---

From: Martin Rex <[email-masked]>
Date: Mon, 25 Aug 2008 13:42:31 +0200 (MEST)

Larry Zhu wrote:
> 
> RFC2743 says that you cannot rely on GSS_Acquire_cred() support for
> any name other than GSS_C_NO_NAME for the intiator.
> 
> 

As Nico already wrote, your reading is not correct.

The behaviour of gss_acquire_cred() given an explicit name for an
intiator or both used to be well-defined, even for GSS-API v1.
But whether a mechanism implemented that well defined behaviour
was an option in v1.  (Do not confuse GSS-API spec with SSPI bugs.)

In GSS-API v2, I asked for two changes that appear in the quoted
paragraph above. 

 (1) gss_acquire_cred() is required to work for the initiator and
     both cases as well (this is no longer an implementation option).

 (2) the names for which gss_acquire_cred() must work for the initiator
     are GSS_C_NO_NAME (i.e. requesting default credentials),
     and for explicit names inquired from previously acquired default
     credentials or inquired from successfully established security
     context.  This requires a small amount of self-consistency
     for implementations.  When using Smart-Card credentials
     the Microsoft Kerberos SSP is defective regarding this consistency
     requirement (it fails).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 25 Aug 2008 13:56:28 +0200 (MEST)

Larry Zhu wrote:
> > attributes, since requesting an anonymous context doesn't mean you
> > got one.  It might be worth noting that if fully anonymous credentials
> > could not be obtained, an implementation might choose to return a
> Fhe full anonymous and partial anonymous should be considered different
> options to the apps. Given that we leave the partial-anonymous option
> (how to invoke and how to check) to implementations, it seems best to
> leave this out as well.

If we thing there is value in defining partial-anonymous in the spec,
we should also standardize how it is to be invoked at the GSS-API level
for all implementations of the Kerberos GSS-API mechanism.

> 
> It seems to me if the app wants to full anonymous, it should get full
> anonymous or fail. It seems overwhelmingly complex to accept partial
> anonymous if full-anonymous is not available upon request. At least
> we so far do not have such a use case for that.

I agree that the current GSS-API spec defines only "fully anonymous",
if anything (although there are unlikely to be any application callers
because there are very few, if any (I do not know any) gssapi mechanisms
that provide that feature.  So the GSS_S_ANONYMOUS_FLAG should only
be returned if fully anonymous is provided.

Whether an how to implement and/or flag partial-anonymous seperately
is a different issue.  I do not feel comfortable with automatic fallback
to partial-anonymous _without_ any indication that this happens/happened.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 25 Aug 2008 15:50:03 +0200 (MEST)

>    upon the successful security context establishment.

I have the impression there is some confusion.

The printable name for the anonymous principal ought *NOT* to be relevant
for the acceptor when performing an authorization decision, simply because
authentication&authorization should be done by either gss_compare_name()
or based on the output of gss_export_name().

Traditional Kerberos uses a name-based authentication.  That name
at the Kerberos protocol level is something entirely different from
the "printable names" at the GSS-API level.

The principal names from the Kerberos protocol level are more
directly related to the exported binary canonical names of GSS-API v2.

-Martin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 25 Aug 2008 10:09:51 -0400

--On Monday, August 25, 2008 01:42:31 PM +0200 Martin Rex 
<[email-masked]> wrote:

> When using Smart-Card credentials

The behavior of the Microsoft Kerberos SSP, which is not a GSS-API 
implementation, is irrelevant to this discussion.  Please focus on the 
issue at hand, and leave the complaints about Windows out of it.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 25 Aug 2008 10:36:11 -0400

> be returned if fully anonymous is provided.

I think we all agree on that at this point.

> to partial-anonymous _without_ any indication that this happens/happened.

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.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 25 Aug 2008 11:05:30 -0400

--On Sunday, August 24, 2008 09:36:46 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> "WELLKNOWN/ANONYMOUS@realm", then apps will be able to depend on
>> mechanisms  which support partial anonymity also supporting those
>> arguments to  GSS_Acquire_cred.
>

Oh, possibly.  My point is just that it doesn't matter if 2743 says 
something is OPTIONAL; if we specify a way to request partial anonymity, 
then applications will be able to rely on that working if partial anonymity 
is supported.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Martin Rex <[email-masked]>
Date: Mon, 25 Aug 2008 17:22:43 +0200 (MEST)

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

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 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).

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().

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.
gss_import_name(NT=partial_anonymous_group,name="group-name") to
result in a partial-anonymous name identifying the explicit group
"group-name".

In order to use this, the initator would need to acquire an explicit
credentials handle and assert the GSS_C_ANONGROUP_FLAG.  When both
flags ANONYMOUS and ANONGROUP are requested by initiator, the
mechanism should attempt fully anonymous and would be allowed to
fail-back on partial-anonymous and would be allowed to fail-back
on regular client-to-server authentication (in theory--the
characteristics of an explicit group-anonymous credential might
preclude fail-back on regular client-to-server authentication).

For the Kerberos gssapi mechanism, we could define the anongroup
to refer to realms.  If, however, the notion of "groups" of
Kerberos principal within a realm should not be precluded,
another, Kerberos-specific nametype with the semantics
anonymous-within-realm and the printable representation
of the realm should be defined&used.

...just a thought.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Aug 2008 10:46:02 -0500

> security context attribute is IMHO a requirement for partial anonymous

I agree.

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

> portable fashion at GSS-API (one additional nametype, one additional

I think that would be a good approach.

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

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

> result in a partial-anonymous name identifying the explicit group

Ah, I see where the group-name comes in.

> ...just a thought.

I like it.

Nico