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

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
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
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman
--On Tuesday, November 23, 2010 04:45:10 PM -0500 [hidden email] wrote:

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

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
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
On Tue, 2010-11-23 at 17:01 -0500, Jeffrey Hutzelman wrote:
> 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.

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.


_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce
In reply to this post by Jeffrey Hutzelman
On Tue, 23 Nov 2010 17:01:29 -0500
Jeffrey Hutzelman <[hidden email]> wrote:

> --On Tuesday, November 23, 2010 04:45:10 PM -0500 [hidden email]
> wrote:
>
> > 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.
>
> 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,
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
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams-2
On Tue, Nov 23, 2010 at 05:16:35PM -0500, Simo Sorce wrote:

> On Tue, 23 Nov 2010 17:01:29 -0500
> Jeffrey Hutzelman <[hidden email]> wrote:
> > 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".
> >
> > [...]
>
> 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.

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
--
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman
In reply to this post by Greg Hudson
--On Tuesday, November 23, 2010 05:10:52 PM -0500 Greg Hudson
<[hidden email]> wrote:

> On Tue, 2010-11-23 at 17:01 -0500, Jeffrey Hutzelman wrote:
>> 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.
>
> 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.


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
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman
In reply to this post by Simo Sorce
--On Tuesday, November 23, 2010 05:16:35 PM -0500 Simo Sorce
<[hidden email]> 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.
> Is this not acceptable ? You are always free to *not* restrict
> 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
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Altman-2
In reply to this post by Nicolas Williams-2
On 11/23/2010 5:26 PM, Nicolas Williams 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 can NOT 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

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


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

signature.asc (498 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams-2
On Tue, Nov 23, 2010 at 06:00:58PM -0500, Jeffrey Altman wrote:
> 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.

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.

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

Agreed.
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce
In reply to this post by Jeffrey Hutzelman
On Tue, 23 Nov 2010 17:44:41 -0500
Jeffrey Hutzelman <[hidden email]> wrote:

> --On Tuesday, November 23, 2010 05:16:35 PM -0500 Simo Sorce
> <[hidden email]> 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.
> > Is this not acceptable ? You are always free to *not* restrict
> > 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.

I do not disagree with this proposal.

Simo.

--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Henry B. Hotz

On Nov 23, 2010, at 3:16 PM, Simo Sorce wrote:

> On Tue, 23 Nov 2010 17:44:41 -0500
> Jeffrey Hutzelman <[hidden email]> wrote:
>
>> --On Tuesday, November 23, 2010 05:16:35 PM -0500 Simo Sorce
>> <[hidden email]> 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.
>>> Is this not acceptable ? You are always free to *not* restrict
>>> 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.
>
> 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>

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

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 [hidden email] 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.
[hidden email], or [hidden email]



_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman
--On Tuesday, November 23, 2010 06:23:24 PM -0800 "Henry B. Hotz"
<[hidden email]> 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
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Russ Allbery
In reply to this post by Nicolas Williams-2
Nicolas Williams <[hidden email]> writes:
> On Tue, Nov 23, 2010 at 06:00:58PM -0500, Jeffrey Altman wrote:

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

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

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 ([hidden email])             <http://www.eyrie.org/~eagle/>
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Henry B. Hotz

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

> The problem is that all these factors combine to create an attractive
> 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
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[hidden email], or [hidden email]



_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams-2
In reply to this post by Henry B. Hotz
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.

Nico
--
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams-2
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
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Martin Rex-2
In reply to this post by Nicolas Williams-2
Nicolas Williams wrote:
>
> 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.

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
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Henry B. Hotz
In reply to this post by Nicolas Williams-2

On Nov 23, 2010, at 11:03 PM, 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.


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.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[hidden email], or [hidden email]



_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Henry B. Hotz
In reply to this post by Martin Rex-2

On Nov 24, 2010, at 7:03 AM, Martin Rex wrote:

> The only way to enable anonymous in a responsible fashion is to ensure
> 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.

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

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?
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[hidden email], or [hidden email]



_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman
In reply to this post by Henry B. Hotz
--On Wednesday, November 24, 2010 10:53:44 AM -0800 "Henry B. Hotz"
<[hidden email]> wrote:

>
> On Nov 23, 2010, at 11:03 PM, 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.
>
>
> 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
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
12