Subject: [Ietf-krb-wg] Anonymous PKINIT and KDC policy

From: [email-masked]
Date: Tue, 23 Nov 2010 16:45:10 -0500 (EST)

MIT krb5 implemented anonymous in 1.8.  We are considering adding an
option to restrict its use to FAST armor, by denying tickets from
anonymous to service principals other than the local krbtgt service.
I'd like to solicit opinions from the working group about whether such
an option is narrow enough to avoid impacting Kerberos
interoperability--and on the other side, whether such a restriction
might be necessary to allow anonymous PKINIT (for the purpose of FAST
armor) in deployments people are aware of.

In theory, it shouldn't be a problem that anyone is able to get a
ticket from the fully anonymous principal (in the realm
WELLKNOWN:ANONYMOUS) to a service in a realm.  Services should, at the
very least, check the realm name of the client principal before
assuming that a ticket implies some affiliation with the service's
home organization.  RFC 4120 section 1.4 is explicit that:

    Possession of a client ticket for a service provides only for
    authentication of the client to that service, and in the absence
    of a separate authorization procedure, an application should not
    consider it to authorize the use of that service.

A service which does not check the realm name is broken not only for
anonymous, but also for federated cross-realm deployments (as
distinguished from cross-realm where all the realms are within an
organization).

However, we've have heard that theory does not match up with practice
in all deployments.  An example is that it's really easy to configure
mod_auth_kerb with "require valid-user", allowing access to a web page
to anyone who can authenticate.  Such a configuration would be secure
until either federated cross-realm or anonymous authentication enters
the picture.  We've heard from the admins of Kerberos deployments
which have refrained from allowing federated cross-realm
authentication out of concern for such broken server configurations.

So, my reasoning for making an exception to the model is that:

  * New preauth mechanisms (such as OTP) require FAST.
  * FAST requires an armor ticket.
  * If host keys are not always available, the armor ticket can only
    be obtained with anonymous PKINIT.
  * Organizations have a legitimate fear of allowing anonymous PKINIT
    for purposes other than FAST armor.
  * Therefore, new preauth mechanisms might be difficult to deploy.

When a KDC implementation adds authorization checks to ticket
issuance, it removes some of the incentive for applications to perform
their own authorization checks, which in turn increases reliance on
that particular KDC implementation.  I'm hoping to mitigate this
impact by tailoring the option very narrowly to deployment for FAST
armor--that is, I'm not proposing to add a generic clientX to serviceY
authorization restriction, or even a generic anonymous to serviceY
authorization restriction.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 23 Nov 2010 17:01:29 -0500

> armor) in deployments people are aware of.

This worries me, because it suggests you are assuming that FAST armor is 
the only legitimate use of anonymous PKINIT, whereas I already have another 
use case in mind.  Basically, you're saying "services won't check client 
names, so we won't issue anonymous tickets because services might 
inappropriately execpt them.  Except, some services need to be able to 
accept anonymous tickets, so we'll go ahead and issue anonymous tickets 
only to those services.  Except, the only such service you're allowed to 
have is ours, because We're Special".

I don't care for any of it, but the We're Special part is particularly 
grating.  As a realm administrator, I reserve the right to set policy to 
myself; software which attempts to impose policy on me is broken.

By adopting this change as you propose it, you'd essentially be 
guaranteeing that anonymous credentials will never be useful for _any_ 
other service, because it won't work out of the box, for mysterious 
reasons, and changing it will require throwing a switch that has a giant 
warning label attached to it.

-- Jeff

---

From: Greg Hudson <[email-masked]>
Date: Tue, 23 Nov 2010 17:10:52 -0500

> warning label attached to it.

I think you're either objecting to the current implementation of
anonymous in MIT krb5, or you're reading something into my text which
wasn't there.

In MIT krb5 1.8; you have to create the anonymous principal to turn on
anonymous auth.  So in that respect, it already doesn't work out of the
box.

With the proposed change:

  * If you don't create the anonymous principal, it's not turned on.
  * If you do create the anonymous principal, then it's turned on for
all uses.
  * If you create the anonymous principal and set (making up a name)
restrict-anonymous = yes in the profile, then it's turned on only for
the TGT.

I'm not sure where the giant warning label comes into play.

---

From: Simo Sorce <[email-masked]>
Date: Tue, 23 Nov 2010 17:16:35 -0500

On Tue, 23 Nov 2010 17:01:29 -0500
Jeffrey Hutzelman <[email-masked]> wrote:

> > I'd like to solicit opinions from the working group about whether
> > such an option is narrow enough to avoid impacting Kerberos
> > might be necessary to allow anonymous PKINIT (for the purpose of
> > FAST armor) in deployments people are aware of.
> 
> This worries me, because it suggests you are assuming that FAST armor
> is the only legitimate use of anonymous PKINIT, whereas I already
> have another use case in mind.  Basically, you're saying "services
> won't check client names, so we won't issue anonymous tickets because
> services might inappropriately execpt them.  Except, some services
> need to be able to accept anonymous tickets, so we'll go ahead and
> issue anonymous tickets only to those services.  Except, the only
> such service you're allowed to have is ours, because We're Special".
> 
> I don't care for any of it, but the We're Special part is
> particularly grating.  As a realm administrator, I reserve the right
> to set policy to myself; software which attempts to impose policy on
> me is broken.
> 
> guaranteeing that anonymous credentials will never be useful for
> _any_ other service, because it won't work out of the box, for
> mysterious reasons, and changing it will require throwing a switch
> that has a giant warning label attached to it.

Jeff,
for Greg's email I assumed the option to restrict anonymous would be a
configuration option. But it won't allow generic restrictions of X to
Y, only a restrict all or nothing approach.
Is this not acceptable ? You are always free to *not* restrict
anonymous and your KDC will happily issue tickets to anonymous as well.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 23 Nov 2010 16:26:14 -0600

On Tue, Nov 23, 2010 at 05:16:35PM -0500, Simo Sorce wrote:
> > [...]

What I would suggest is that there be a per-principal flag indicating
whether the realm admin {knows the principal can deal with anon clients,
knows the principal canNOT deal with anon clients, doesn't know if the
principal can deal with anon clients [default]}, and a realm-wide flag
indicating what the TGS will assume when that per-princ flag is set to
"don't know".  Just a big hammer won't do.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 23 Nov 2010 17:32:08 -0500

> I'm not sure where the giant warning label comes into play.

Hrm, OK.  It sounded like you were proposing to enable restrict-anonymous 
by default, in which case the warning label is against turning it off.  Of 
course if you do this, people will start recommending turning it on, and 
we're in (almost) the same spot.

I guess I'd rather see a per-service bit, along the same lines as the bit 
that already exists to designate a service as a password-changing service 
(to which the AS will issue a ticket even if the password is expired).  I 
know this slides a bit farther down the authorization-in-KDC slope, but I 
think it's warranted in this case.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 23 Nov 2010 17:44:41 -0500

> anonymous and your KDC will happily issue tickets to anonymous as well.

But it's not "all or nothing".  It's "all except krbtgt, or nothing".  I 
think I agree with Nico here -- we need a service-specific knob, and it 
needs to be tristate with the default being the "unspecified" state, the 
effect being that we can set the default via a config option and override 
it on a per-service basis.

-- Jeff

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 23 Nov 2010 18:00:58 -0500

On 11/23/2010 5:26 PM, Nicolas Williams wrote:

> knows the principal can NOT deal with anon clients, doesn't know if the

There are two concerns I have:

1. Any restriction on what client principals may be used to obtain
   tickets for some other principals in effectively an authorization
   check.  Such a check is bad enough when the functionality is
   effectively "turn on FAST but not anonymous for other purposes".

   As soon as there is a per principal flag that indicates whether
   ANONYMOUS@WELLKNOWN:ANONYMOUS may be used there will be a demand
   for a flag to determine if ANONYMOUS@<ANY-REALM> may be used.
   That leads to the desire for configuration data to restrict
   ANONYMOUS@THIS-REALM but permit others.  By the time you are done
   you have the Kerberos KDC acting as a full fledged authorization
   service deciding which services may be accessed.

   Other authorization checks that will be requested are:
    a. was FAST used for preauth
    b. was a smart card used or a particular class of cards
    c. was a OTP used
    d. etc.

2. In the case of authorization denials, there is a significant
   question of what the error should be.  RFC 4120 explicitly states
   that the KDC is not an authorization service and so there is no
   effort to describe how authorization errors should be reported
   to the client.  KRB_ERR_GENERIC is not a good choice and is already
   far to over used.  KRB_ERR_POLICY is in fact worse since it conveys
   no useful data to the end user or the help desk personnel as to
   what the user needs to do differently in order to access the given
   service.

   Applications do a horrible job as it is conveying Kerberos errors
   to the user.   Applications are written to handle authorization
   failures within the application protocol.

If it is known that mod_auth_kerb (or any other application) is written
such that it violates the authentication and authorization guarantees of
the Kerberos protocol, then it is the responsibility of this community
to point out the problem to the product and get it fixed.  I do not
believe it is appropriate for the Kerberos protocol to be turned into an
authorization protocol simply because it has been misused as one in the
past.

That being said, if the Kerberos protocol is to become an authorization
protocol, then I believe that the mechanisms by which it can be used as
such need to be documented and standardized in this working group.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 23 Nov 2010 17:12:55 -0600

> authorization protocol simply because it has been misused as one in the

I certainly prefer to have the apps fixed.  I'm not sure that's
realistic, but I'd like to see some analysis of that.

> such need to be documented and standardized in this working group.

Agreed.

---

From: Simo Sorce <[email-masked]>
Date: Tue, 23 Nov 2010 18:16:26 -0500

On Tue, 23 Nov 2010 17:44:41 -0500
Jeffrey Hutzelman <[email-masked]> wrote:

> > for Greg's email I assumed the option to restrict anonymous would
> > be a configuration option. But it won't allow generic restrictions
> > of X to Y, only a restrict all or nothing approach.
> But it's not "all or nothing".  It's "all except krbtgt, or
> nothing".  I think I agree with Nico here -- we need a
> service-specific knob, and it needs to be tristate with the default
> being the "unspecified" state, the effect being that we can set the
> default via a config option and override it on a per-service basis.

I do not disagree with this proposal.

Simo.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 23 Nov 2010 18:23:24 -0800

> I do not disagree with this proposal.

<MIT>
Assuming we go this route (which needs more discussion), I think tri-state is overkill.  At least back it off to a principal creation default value, which is resettable per-principal.  I think requiring manual creation of the anonymous principal to enable the feature overall is reasonable.
</MIT>

>>>>  * Therefore, new preauth mechanisms might be difficult to deploy.

Since this is IETF, not krbdev@mit, I think the real question to discuss -- as both Jeffrey's have said -- is how far down the slippery slope of authorization should we recommend people go.  I think Greg makes a convincing argument for doing something.

However, speaking for myself, I've been sufficiently vocal about telling people they need to know how to handle a fully encrypted, authenticated connection from [email-masked] that I would have no qualms about fully enabling anonymous tickets.  Furthermore, it seems like it would be really easy to scan for apps that do the wrong thing.

In other words, if we write an RFC covering this subject, I'd vote for:
SHOULD	all-or-nothing
MAY	FAST-only
only-if-you're-compulsive	{en,dis}able per-principal

If you want to upgrade that to MUST/SHOULD/MAY, I wouldn't oppose it.

-------

Having said that, if this wg wants to flesh out how to do authorization in a general, interoperable way, I support that.  For example, I'd like a way to restrict access based on 800-63 levels of assurance, which in turn depend on whether the original authentication was done via password, OTP, or PKINIT.  NASA has worked out an elegant way to do that with Microsoft, but for JPL that's least useful for precisely the user community who would most make use of it.

This is drifting off-topic, and I'm kind of busy now.  If enough people bug me (off-list) I might write up my thoughts on the subject.  

My experience with authorization is that clear requirements tend to be application specific, and attempts to create a generic framework seem to rathole.  A simple how-did-we-authenticate if-relevant authorization data type might be narrow enough to avoid the problems with generic authorization data.

I still think the general authorization problem is worth solving.

<apache-nit>
mod_auth_kerb lets you list the allowed realms, so you can exclude AL-QAEDA.INT, even if you're not doing ldap (or shibboleth, or other) authorization.
</apache-nit>
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 23 Nov 2010 21:57:03 -0500

--On Tuesday, November 23, 2010 06:23:24 PM -0800 "Henry B. Hotz" 
<[email-masked]> wrote:

> Having said that, if this wg wants to flesh out how to do authorization
> in a general, interoperable way, I support that.  For example, I'd like a
> way to restrict access based on 800-63 levels of assurance, which in turn
> depend on whether the original authentication was done via password, OTP,
> or PKINIT.  NASA has worked out an elegant way to do that with Microsoft,
> but for JPL that's least useful for precisely the user community who
> would most make use of it.

Speaking here as an individual...

So, I think it's always going to be the case that KDC's do some 
authorization checks regarding when they are willing to issue tickets.  For 
example...

* KDC's normally keep expiration dates on principals and passwords, and
  will issue some but not all tickets when a password is expired.  As OTP
  mechanisms get deployed, we can imagine a KDC which is willing to issue
  tickets for a particular OTP backend's password-changing service, even
  after it will no longer issue service tickets.
* Many KDC's keep per-principal bits indicating whether a principal may
  be used as a client or service.
* Some KDC's keep per-principal bits indicating whether service tickets
  may be issued for a principal by the TGS.
* The protocol specification presumes that KDC's may apply a policy
  as to authentication paths that will be permitted for cross-realm
  tickets presented to the TGS.
* Some KDC's keep per-principal bits indicating whether a principal
  may obtain postdated, renewable, or forwardable tickets.
* Some KDC's keep per-prinicpal policy describing what preauth methods
  must be used for a principal to obtain an initial ticket.

At some point we have to figure out where to draw the line.  Personally, 
I'm not enamored of generalized policy describing when a particular client 
may obtain tickets for a particular service.  However, I do think it's 
reasonable to have policy that applies generally to a client principal or 
to a service principal, particularly with regard to core features and to 
protocol extensions.  Saying "this principal may/may not be used with this 
feature" seems to me to fall into this category.

That said, others may wish to allow the KDC considerably more latitude in 
deciding when to issue tickets, pushing authorization checks that are 
traditionally done in applications to the KDC instead.  If we still think 
that's a bad idea, maybe we need to reiterate that position.

On the other hand, if we decide we do want to go there, I think the most 
important work for this WG is not describing authorization checks the KDC 
can make, but in providing better information when the KDC decides not to 
issue a ticket as a matter of policy.

> My experience with authorization is that clear requirements tend to be
> application specific, and attempts to create a generic framework seem to
> rathole.  A simple how-did-we-authenticate if-relevant authorization data
> type might be narrow enough to avoid the problems with generic
> authorization data.

It does seem that providing more information on how initial authentication 
happened would be useful to applications.  It might also be useful to 
provide some small level of abstraction, so that every application doesn't 
have to understand every possible preauth scheme to know which ones are 
appropriate.  In fact, it almost seems appropriate to provide a simple but 
generic framework by which a KDC can communicate this information in terms 
of realm-specific properties which can then be referred to in application 
configuration.

For example, JPL might define a "Level3" property which is set by the KDC 
if authentication is obtained by PKINIT or OTP, and an "Level4" property 
which is set only when authentication is obtained by PKINIT using a 
certificate signed by a particular CA (which is known to issue certificates 
only to hardware tokens).

Note that in practice, such things may make the user experience more 
annoying, since you may end up with a TGT that can be used to obtain usable 
service tickets for some applications but useless tickets for others. 
Having the KDC refuse to issue the "useless" tickets does not seem like it 
would have any notable effect on this.

-- Jeff

---

From: Russ Allbery <[email-masked]>
Date: Tue, 23 Nov 2010 19:50:43 -0800

>> such that it violates the authentication and authorization guarantees
>> of the Kerberos protocol, then it is the responsibility of this
>> community to point out the problem to the product and get it fixed.  I
>> do not believe it is appropriate for the Kerberos protocol to be turned
>> into an authorization protocol simply because it has been misused as
>> one in the past.

> realistic, but I'd like to see some analysis of that.

I don't see how there's anything here that can possibly be fixed in an
application.  There is nothing wrong with mod_auth_kerb's behavior.  The
"require valid-user" has nothing to do with mod_auth_kerb and
mod_auth_kerb has no knowledge of it.  mod_auth_kerb, as an Apache
authentication module, has no obligation other than to report the
authenticated identity to Apache, which it has done.  The authorization
configuration is done separately in Apache.

There is no single piece of software at fault that can be fixed.
mod_auth_kerb is working properly by reporting the correct authentication.
Kerberos is working properly by allowing a properly labelled weak
authentication.  Apache is working properly by honoring the user's
configured authorization rule (allow any authenticated user).

The problem is that all these factors combine to create an attractive
nuisance.  Or, put another way, most people live in a world where
"authentication" means something other than anonymous, because they're
used to password authentication or use of LDAP simple binds as an
authentication service or something similar.  The idea of an anonymous
authentication is perfectly sensible in theory, but it's very surprising.
It's a very sharp tool that users who don't have a good mental grasp of
authentication and authorization models and are just trying to get their
service to apparently work (not reject valid users) are unfortunately
likely to create security holes with.

Just look at how many Kerberos applications did authorization on Kerberos
identities without regard for the realm, which is a much harder mistake to
make.  We as a community fought that problem for more than a decade, and I
suspect there are still apps out there with that problem.

Anonymous authentication introduces a concept that the average person
deploying a security application isn't familiar with, and which behaves in
a very surprising way in existing Kerberos installations.  (And let me say
this explicitly, since I think it's often lost in discussions that tend to
be dominated by people who have been heavy Kerberos users for years: I
believe the typical Kerberos installation does not do any cross-realm
except possibly between multiple blessed corporate Active Directory
realms.  Cross-realm is already a very surprising idea, and I know many
sites that have a local policy against ever doing cross-realm because of
its surprising behavior given how they are currently thinking about
Kerberos authentication.)

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 23 Nov 2010 22:56:38 -0800

On Nov 23, 2010, at 7:50 PM, Russ Allbery wrote:

> nuisance.

+1

I'm repeating myself, but it's an easy problem to scan for.  That puts one in a different branch of the bureaucratic tree, which may be helpful.  YMMV

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Nov 2010 01:03:45 -0600

On Wed, Nov 24, 2010 at 01:03:17AM -0600, Nicolas Williams wrote:
> On Tue, Nov 23, 2010 at 06:23:24PM -0800, Henry B. Hotz wrote:
> > <MIT>
> > Assuming we go this route (which needs more discussion), I think
> > tri-state is overkill.  At least back it off to a principal creation
> > default value, which is resettable per-principal.  I think requiring
> > manual creation of the anonymous principal to enable the feature
> > overall is reasonable.
> > </MIT>
> 
> IMO, a boolean instead of tri-state setting will make this problem
> harder to manage, thus I'd rather have a tri-state setting.

That is, if we must have one at all.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Nov 2010 01:03:18 -0600

Nico

---

From: Martin Rex <[email-masked]>
Date: Wed, 24 Nov 2010 16:03:59 +0100 (MET)

> realistic, but I'd like to see some analysis of that.

This is not an apps problem, it would definitely a Kerberos protocol
failure if it comes to apps as an surprise.

The only way to enable anonymous in a responsible fashion is to ensure
that the installed base will consider it an invalid authentication.
And updated deployments ought to ensure that only apps that consciously
enable anonymous authentications to succeeds should see them succeed,
for all others, the authentication ought to continue failing.

Consciously enable meaning that changing the app is required to perform
an explicit API call into the Kerberos server implementation to enable
the feature.

The issue that you have is that existing "access control" is based
on the historic infrastructure and requirements.  Existing ACLs are
not suited to expand trust to arbitrary other realms or anonymous
principals.  Most objects are created without explicit ACLs, but
instead, with some default setting of "everyone/world" and the notion
that everyone/world is a fairly small, clearly identifiable group.

If you want to suddenly allow "anonymous" or expand the definition
of "everyone/world" from a few dozen to 6.5 billion, then every
service will have to check the access control mechanims (and/or ACLs)
for every object / every piece of information that it makes accessible
for compatibility with the redefinition of that group.

A Unix umask of 022 does not imply that someone really intends
to make ALL data he creates readable for all mankind and beyond.
The notion of what a 022 may also vary greatly between home installations
of Users and data created by students on campus workstations on an
AFS-enabled network drive (or whatever is in use today).

I think that redefining the scope of existing groups, such as "other" (Unix)
or "Everyone" (NT) or "Authentictad Users" (NT) to cross-organization
is a bad idea.  Instead, new groups that have exactly this semantics
should be created, and implementations ought to ensure that they
become visible only to apps that "subscribe" to these new groups.

-Martin

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 24 Nov 2010 10:53:44 -0800

> harder to manage, thus I'd rather have a tri-state setting.

I wonder if the difference of opinion isn't based on Heimdal vs MIT.  Heimdal has no such thing as a policy.  Instead such things are always set on a per-principal basis, or are inherently global.  If a principal named "default" exists, then a bunch of stuff (possibly including an allow-anonymous flag) gets copied from it into newly-created principals.

It's possible I don't know what I'm missing, but I haven't missed having the extra layer so far.  OTOH if we want to create a generic way of handling authorization data then I suspect the per-principal model won't work.  An extra abstraction layer akin to policies might be necessary.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 24 Nov 2010 11:20:25 -0800

> that the installed base will consider it an invalid authentication.

OK, I guess I'm in the rough.  I shouldn't be surprised that most people don't feel they can be as hard-nosed on the point as I'd like to be.

> an explicit API call into the Kerberos server implementation to enable

I agree with the argument that the feature should be controlled by the app admin, not the Kerberos admin.  *I* don't want the headaches associated with managing such a feature since *I* don't know what the individual capabilities of all of my service users are.

Any suggestions for how to accomplish that?  

The obvious way I see is to enhance your service principal issuance process to support setting the flag we've discussed.  That's really providing the control outside Kerberos itself.  That's effectively punting on the issue.

How about an enhancement to kadmin or kpasswd to allow a principal to set the flag for itself?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 24 Nov 2010 14:44:42 -0500

--On Wednesday, November 24, 2010 10:53:44 AM -0800 "Henry B. Hotz" 
<[email-masked]> wrote:

> I wonder if the difference of opinion isn't based on Heimdal vs MIT.
> Heimdal has no such thing as a policy.  Instead such things are always
> set on a per-principal basis, or are inherently global.  If a principal
> named "default" exists, then a bunch of stuff (possibly including an
> allow-anonymous flag) gets copied from it into newly-created principals.

I don't think anyone in this discussion has used the word "policy" in the 
sense of that abstraction layer.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Fri, 26 Nov 2010 10:48:01 -0500

Hmm.
I'd actually argue that mod-auth-kerb should report no identity to
Apache if anonymous authentication is taking place.

One thing we might want to consider is the default behavior of our
libraries when faced with an anonymous ticket.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Russ Allbery <[email-masked]>
Date: Fri, 26 Nov 2010 10:54:51 -0800

> Apache if anonymous authentication is taking place.

Hm... yeah, actually, I guess I could see an argument for that.