Subject: RE: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 19 Oct 2005 22:28:38 -0700

What you suggested definitely makes sense to me. We shall define one by
all means.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2005 6:13 AM
To: Nicolas Williams
Cc: Liqiang(Larry) Zhu; [email-masked]; [email-masked]
Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt

Nicolas Williams wrote:
> 
> Q:  How will old implementations handle principal names that are empty
>     sequences?

The use of an empty (zero-length) string for the printable
representation
of the Kerberos principal name would be a problem, because it would
be an illegal parameter at the GSS-API level.

As has been suggested in the GSS-API long ago, a gssapi mechanism that
implements an anonymous principal should define a non-empty
printable representation for it.

-Martin

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Fri, 21 Oct 2005 17:11:04 +0200

Using anonymous@anonymous as the printable representation would be bad
since is wouldn't allow the application to select the realm that is want to
use when contacting the server (client selection).

I'll try to explain what I mean with an example.

I trust the KDC for SU.SE to keep my anonymity, but not so sure about
KTH.SE. So when contacting a server in KTH.SE I want to do a cross realm
jump with a anonymous principal. But since I've both got inital credentials
for SU.SE and KTH.SE, I want to be able to tell the gss-api layer, "use my
SU.SE credential and be anonymous".

How about anonymous@anonymous when I don't care, and anonymous@REALM when I
don't ? This have namespace issues so I'm not so sure how much I like it.

Love

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Oct 2005 13:05:29 -0500

> don't ? This have namespace issues so I'm not so sure how much I like it.

Sure, and it sounds like a job for the GSS naming extensions if you want
to go further than that.

I still think the cname should not be an empty SEQUENCE of components,
instead the client should use an authorization-data element.

With Ticket extensions we could even ask that the KDC "allocate" a
unique anon name and tell the client, or maybe we could do that now with
pre-auth.

Anyways, I know I don't like the empty SEQUENCE of components.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 21 Oct 2005 12:04:21 -0700

Allow me to clarify the I-D a bit:
 
in order to request anonymous service at the GSS-API level, you need present both of the following two things:
 
1) your credentials, this includes which realm you intend to contact.
 
2) your intention to request anonymous service. Implementation wise, I would use SSPI as an example, in addition to your username, realm name, password/smartcard/other-credentials, you should also supply a flag to request anonymous tickets, it is very similar to the way how you request  not to have the PAC in your tickets today.
 
In other words, selecting which credentials to use and requesting anonymous service are orthogonal, and should be treated as such. But note you need valid credentials in all cases.
 
in your example, you seemed to attempt to overload the user name in order to request anonymous tickets. this is not what I intended and it does not work. if you want to request an anonymous TGT from realm SU.SE, you can pick your account in SU.SE. 
 
If you pick your credentials in SU.SE, then in order to go to realm KTH.SE,
you have to do cross-realm authentication. You can not pick your account at SU.SE and try to contact KTH.SE, if you do that, you could reveal your identify to KTH.SE, but I can not think a reason why you would want to request an initial TGT using the credential from SU.SE. Do we need to clarify this a bit and make sure implementations would make such mistakes?
 
perhaps we should add details how to implement this extension in GSS-API/SSPI, since most of questions so far are related to GSS-API/SSPI. 
 
however, shall we have a separate I-D, or just add such details to this I-D? what is your opinion?

________________________________

From: Love Hörnquist Åstrand [mailto:[email-masked]]
Sent: Fri 10/21/2005 8:11 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; Nicolas Williams; [email-masked]; [email-masked]
Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt

Love

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 21 Oct 2005 12:04:50 -0700

"empty SEQUENCE" is the only thing I believe we can count on that older implementations will always fail if they do not support anonymity as defined in this I-D.

From: Nicolas Williams [mailto:[email-masked]]
Sent: Fri 10/21/2005 11:05 AM
To: Love H?rnquist ?strand
Cc: Liqiang(Larry) Zhu; [email-masked]; [email-masked]; [email-masked]
Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Oct 2005 14:12:47 -0500

On Fri, Oct 21, 2005 at 12:04:50PM -0700, Liqiang(Larry) Zhu wrote:
> "empty SEQUENCE" is the only thing I believe we can count on that
> older implementations will always fail if they do not support
> anonymity as defined in this I-D.

Why not have an exceedingly-unlikely-to-have-been-used name?

I worry about security bugs in older implementations.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 21 Oct 2005 15:18:37 -0400

> I worry about security bugs in older implementations.

So do I.  Imagine an older implementation which renders the empty sequence 
as the empty string (an entirely reasonable thing to do).  Now, what 
happens if the proposed anonymous principal is passed to krb5_kuserok, and 
the .k5login file contains an empty line?  Or maybe even a comment?

We do not appear to have left ourselves any mechanism for "reserved" 
principal names which appear in all realms, aside from the 'krbtgt' name.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Oct 2005 14:34:04 -0500

On Fri, Oct 21, 2005 at 03:18:37PM -0400, Jeffrey Hutzelman wrote:
> On Friday, October 21, 2005 02:12:47 PM -0500 Nicolas Williams wrote:

Authorization-data.

---

From: Tom Yu <[email-masked]>
Date: Fri, 21 Oct 2005 15:38:57 -0400

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

jhutz> On Friday, October 21, 2005 02:12:47 PM -0500 Nicolas Williams

>> I worry about security bugs in older implementations.

jhutz> So do I.  Imagine an older implementation which renders the empty
jhutz> sequence as the empty string (an entirely reasonable thing to do).
jhutz> Now, what happens if the proposed anonymous principal is passed to
jhutz> krb5_kuserok, and the .k5login file contains an empty line?  Or maybe
jhutz> even a comment?

There could be some ambiguity between the string representation of a
principal consisting of a sequence of zero members, and that of a
principal consisting of a sequence of one zero-lenght member.

Also, empty sequences as principal names _have_ been security
vulnerabilities for some implementations.

---Tom

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 21 Oct 2005 15:41:49 -0400

On Friday, October 21, 2005 02:34:04 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> So do I.  Imagine an older implementation which renders the empty
>> sequence  as the empty string (an entirely reasonable thing to do).
>> Now, what  happens if the proposed anonymous principal is passed to
>> krb5_kuserok, and  the .k5login file contains an empty line?  Or maybe
>> even a comment?
>>

That's not the same thing as a reserved principal name.  It doesn't fit in 
all principal-name-slots, in Kerberos or in Kerberos-using protocols.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Oct 2005 15:28:08 -0500

> all principal-name-slots, in Kerberos or in Kerberos-using protocols.

But authz-data allow us to represent the desired semantic: that whatever
the name is, it's not meaningful for authorization.

Then the name could be anything, set by local convention, randomized
even.

---

From: Martin Rex <[email-masked]>
Date: Fri, 21 Oct 2005 22:45:29 +0200 (MET DST)

There are different technical issues to address in GSS-API and
in the underlying Kerberos when dealing with anonymous principals.

At the GSS-API level, the use of an anonymous principal by 
the initiator/client requires a software change of the initiator/client
software (to assert the "anonymous" flag when calling gss_init_sec_context).

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 initator/client. 
The printable name is relevant for the acceptor/server when performing
an authorization decision based on the name that pops up from
gss_accept_sec_context upon successful security context establishment.

A gssapi 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".

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 21 Oct 2005 22:54:45 +0200 (MET DST)

> Then the name could be anything, set by local convention, randomized

GSS-API v2 seems to have the necessary distinguishing hooks at its level
(which I forgot), it defines a special Nametype for the anonymous
principal, so that it can be used in a "portable" (=mechanism independent)
fashion, provided that the mechanism actually implements the necessary
logic.

The may be an issue for installed-base servers: do you want them to
get to see a principal name that they will hardly confuse with
any existing name, or do you prefer if they entirely abort the
authentication?

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Oct 2005 16:04:28 -0500

> in the underlying Kerberos when dealing with anonymous principals.

All very good and well, but we are discussing how clients/KDCs will
represented anonimity in KDC exchanges and in Tickets.  We can't even
get beyond that discussion!

> by or relevant for the initator/client. 

But it does define GSS_C_NT_ANONYMOUS and anonymous names, so it stands
to reason that credentials for anonymous names are anonymous
credentials.

In this case, of course, the credentials aren't "anonymous" -- the TGT
presumably bears the user's principal name.  Instead the initiator
should use the anon flag (GSS_C_ANON_FLAG).

But I could see a mechanism with no authenticated initiator, acceptor or
either (e.g., SPKM-3 is supposed to allow for unauthenticated/
unidentified initiators).  And how would an application acquire a
credential for such a mechanism?  I figure: use GSS_C_NT_ANONYMOUS.

> gss_accept_sec_context upon successful security context establishment.

But GSS_Display_name() can indicate that the name is of
GSS_C_NT_ANONYMOUS type too, so the actual name may not be so important.

> something that can rarely be "un-done".

Shouldn't the initiator have to check on every call to
GSS_Init_sec_context() though?  What if the given mech's first context
token never reveals the initator identity but subsequent context tokens
may?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Oct 2005 16:07:05 -0500

> fashion, provided that the mechanism actually implements the necessary

Darn, I should have read this first :)  I just replied to your other
post to point out GSS_C_NT_ANONYMOUS...

> any existing name, or do you prefer if they entirely abort the

I say: let them see whatever you want them to see, possibly random
garbage (guaranteed by the KDC, say, never to have previously been
meaningful in that realm), provided that they also see a critical
indication of anonymity, that the name is not useful for authorization.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 21 Oct 2005 17:07:34 -0400

> something that can rarely be "un-done".

This has always been something of a concern to me, more so now that we are 
contemplating adding anonymous authentication support to Kerberos.  In 
order to protect is anonymity, a client pretty much has to do what you 
describe; the problem is that the context is not yet fully established, and 
so the attributes might not be valid.  For example, it's not reasonable to 
assume that a context will not support integrity just because it doesn't 
have that attribute after the first call; why is that OK for anonymous?

(Maybe some of this belongs in kitten?)

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Oct 2005 16:35:25 -0500

> have that attribute after the first call; why is that OK for anonymous?

We might be able to do this now:

anon_name = GSS_Import_name(GSS_C_NT_ANONYMOUS, "anonymous" [or "garbage"]);
anon_cred = GSS_Acquire_cred(anon_name, {krb5});

And have the krb5 mech find any TGT it can and use it.  Or if you use
"anonymous@REALM" w/ GSS_C_NT_KRB5_ANONYMOUS then you could tell the
krb5 mech to use the first TGT it can find for a principal in that
realm.

> (Maybe some of this belongs in kitten?)

Maybe.  I've been thinking of a GSS_Acquire_cred_with_cred() function --
think of Kerberos<->PKI bridges.

Here we want to use an existing credential (a TGT) to acquire another
that does not reveal the identity normally authenticated by that
credential.

So,

    my_normal_cred = GSS_Acquire_cred(GSS_C_NO_NAME, {krb5});
    anon_name = GSS_Import_name(GSS_C_NT_ANONYMOUS, "anonymous" [or "garbage"]);
    anon_cred = GSS_Acquire_cred_with_cred(my_normal_cred, anon_name, {krb5});

This would be better, yes.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 21 Oct 2005 23:39:53 +0200 (MET DST)

> to reason that credentials for anonymous names are anonymous

Not really.  Actually the existing GSS-API v2 spec defers the gory
details to the mechanism (spec).  What it does say is this (rfc2743, 1.2.5):

   In ordinary GSS-API usage, a context initiator's identity is made
   available to the context acceptor as part of the context
   establishment process.  To provide for anonymity support, a facility
   (input anon_req_flag to GSS_Init_sec_context()) is provided through
   which context initiators may request that their identity not be
   provided to the context acceptor.  Mechanisms are not required to
   honor this request, but a caller will be informed (via returned
   anon_state indicator from GSS_Init_sec_context()) whether or not the
   request is honored. Note that authentication as the anonymous
   principal does not necessarily imply that credentials are not
   required in order to establish a context.

So the requirement is the use of the input anon_req_flag.
A fallback to regular authentication could be a problem if
an application tried to acquire "anonymous" credentials.

> credential for such a mechanism?  I figure: use GSS_C_NT_ANONYMOUS.

Portable initiators are recommended to use **default** credentials
whenever possible, and request anonymity only through the
"input anon_req_flag" to gss_init_sec_context.

> GSS_C_NT_ANONYMOUS type too, so the actual name may not be so important.

The primary purpose of gss_display_name() is to create a printable
representation, and I assume that quite often the printable
representation will be written to the logfile and the acutal OID
completely ignored (because most humans don't recognize OIDs).

> token never reveals the initator identity but subsequent context tokens

Ooops -- you are correct!
For multiple round-trip security context exchanges the determination
of whether anonymity can be provided may not be possible on the
initial call to gss_init_sec_context().

So the rule will have to be that a mechanism (that supports anonymity)
must indicate the GSS_C_ANON_FLAG on every return from gss_init_sec_context
for as long as it tries to achieve it and there is still hope this
succeeds, and it must clear the flag as soon as it creates a token
that would reveal the initiators identity, so that the initiator
can realize it and abort without sending that particular context
token.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 21 Oct 2005 23:54:55 +0200 (MET DST)

> have that attribute after the first call; why is that OK for anonymous?

Try to look at it from a different perspective:
The flags need to be valid as soon as they become relevant for
an application decision.

Prior to PROT_READY the integrity flag was relevant only for the
final call, because that was the first time that an application
would use message protection service.

With the addition of PROT_READY, the message integrity and confidentiality
flag must become valid whenever PROT_READY becomes valid--and when
PROT_READY is not available or applicable, this is again the
final call if it succeeds.

> (Maybe some of this belongs in kitten?)

Maybe we should migrate the thread?

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Oct 2005 16:58:09 -0500

> Maybe we should migrate the thread?

The GSS discussion should move to KITTEN, yes.

But we also have to hash out the Kerberos-specific issues.  How we
represent anonymous/unidentified principals in Ticket seems quite
independent of how this feature might be used in the context of the
GSS-API.  That discussion should stay here, at least until we discover,
if we discover, that it's very closely related to the GSS issues.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Sat, 22 Oct 2005 00:13:01 +0200 (MET DST)

> to reason that credentials for anonymous names are anonymous

I do not agree.

> credential for such a mechanism?  I figure: use GSS_C_NT_ANONYMOUS.

Although nothing prevents a gssapi mechanism to implement that
and nothing prevents applications to request that, 
portable applications will NOT normally do this, and IMHO
this model is too complex for my taste.

First issue: what is a credential?
IMHO, a credential is (secret) information that enables you
to authenticate yourself to others, and it often includes
(secret or public, but trusted) information that enables
you to authenticate others.

Think of SSL:
An SSL credential is normally an RSA-keypair plus a list
of trust anchors that enables you to authenticate your peers.

Nowadays anonymous SSL clients are the norm (as far as the
authentication at the SSL level is concerned), and Browsers
with SSL client certs are the exception.  But even with
an SSL client cert installed and when talking to a Web-Server
that requests SSL client certs and has announced that
he trusts the CA which signed our SSL client cert, most
Browsers offer the possibility for the user to decline
the use of the SSL client cert.  However you still want/need
the list of trust anchors to verify the Servers identity
(in most cases).

Whether you can just skip the initiator-to-server authentication
in a PKI-based protocol just as in the SSL case, or whether
you need to invent anonymous tickets (on the fly and under the covers) 
for a Kerberos based gssapi mechanism depends on each
individual mechanisms.

Whether you use anonymous TGTs or just anonymous service tickets,
and whether you trust one KDC but not the other to live up to your
anonymity requirements is also an implementation detail -- as
far as portable GSS-API based applications are concerned.

If have special requirements for your management of anonymous
credentials, try to steer it through your mechanism-specific
credential management tool(s).  PLEASE do NOT put the burden to
make such distinctions on the (portable) GSS-API based applications
and do not expect them to mess around with credentials management
calls in fancy ways.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Oct 2005 19:45:52 -0500

> you to authenticate others.

Such as an ephemeral Diffie-Hellman exponent.  Good enough for
unauthenticated key exchange.