[15721] in Kerberos_V5_Development
Re: Proper way to do logging (KDC) from preauth plugin?
daemon@ATHENA.MIT.EDU (Jeff Blaine)
Wed Apr 28 11:39:08 2010
Message-ID: <4BD85693.607@kickflop.net>
Date: Wed, 28 Apr 2010 11:38:59 -0400
From: Jeff Blaine <jblaine@kickflop.net>
MIME-Version: 1.0
To: Sam Hartman <hartmans@mit.edu>
In-Reply-To: <tsly6g7k4f0.fsf@mit.edu>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
> I think that configuration of which pa types should be required for a
> given user don't belong in a PA_REQUIRED flag.
Reflecting more on it, FWIW, I completely agree. That thought was
really just a desperate attempt to find some immediate way
to make any sort of progress in my project, intentionally
ignoring any long-term relevance or correctness. I may
even continue down that path for the sake of getting
*anything* working the way I need it to in our exploratory
code. (ugh)
> I think if you're looking for a facility to decide whether a particular
> request should be honored that always runs against the request, then you
> would need a new facility. I think designing such a facility will be a
> bit tricky. Using that type of facility for environment-specific
> restrictions seems fine. For example: in our environment, we never want
> to let certain users log in outside of working hours.
>
> However, using such a facility to limit access to specific services
> seems highly problematic from a secure interoperability standpoint. RFC
> 4120 requires services to handle authorization. If some KDCs in some
> environment will handle some of the authorization, but other KDCs in
> other environments do not, then it seems very easy to get a class of
> services that are not interoperable with a general purpose KDC or that
> are not secure when used with such a KDC. I'm strongly against that.
From my part of the conversation, none of this is intended to be
used for authorization. The goal is to require a specific
pre-authentication succeeds before considering the granting of
a TGT (for any intended purpose).
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
