krb5-1.5-alpha1 is available

[greg@enjellic.com]

On May 31, 11:50am, Sam Hartman wrote:
} Subject: Re: krb5-1.5-alpha1 is available

> >>>>> "greg" == greg  <greg at enjellic.com> writes:
> 
>     greg> On May 31, 2:55am, Tom Yu wrote: } Subject: krb5-1.5-alpha1
>     greg> is available
> 
>     >> Major changes in 1.5 - ----------------------
>     >> 
>     >> Merged to the trunk and included in this alpha release:
>     >> 
>     >> * plug-in architecture (in-progress)
> 
>     greg> Is the plug-in architecture only to support multiple
>     greg> databases or is it a generic mechanism which will support
>     greg> authorization payload injection and the like?

> Long term, it will support authorization injection; there is not
> currently a plugin for this.

I assume it would be a straight forward exercise.

>     greg> Based on our experiences and other issues which consistently
>     greg> pop-up on the list the ability to intercept and modify, at a
>     greg> minimum, AS_REQ and TGS_REQ handling is needed.

> We're probably not all that interested in plugins that would
> encourage violation of RFC 4120, but we are definitely interested in
> preauth and authz_data plugins.

I would be interested in your definition of violating RFC4120.  One
would certainly not want to violate the form in which things fly over
the wire.

That being said there would seem to be a number of reasons for the
interception of AS_REQ and TGS_REQ handling.

Consider authorization.

Within our identity model every service conveyed by an organization to
an individual is considered a service subject to authorization. This
includes Kerberos authentication.  Turning off authorization for
Kerberos denies the user the ability to obtain a TGT.

We implement this by intercepting AS_REQ handling.  An authorization
check is run against the requesting principal to determine if they are
authorized for the KERBEROS service.  Failing this check causes a
'principal unknown' error to be returned to the client.

It doesn't seem logical that 'principal unknown' due to an
authorization failure should be a protocol violation any more than
'principal unknown' due to a principal not being found in the backing
store.

AFS is an example I use in my Ann Arbor talk as a rationale for
intercepting TGS_REQ requests.  A service ticket request for a
principal of the form afs at REALM causes an authorization check against
the principal in the presented TGT.  If the user has not been granted
AFS services the client sees a 'server unknown' error.

Identity translation is also an issue requiring AS_REQ interception.
I will need to ponder RFC4120 to see if anything precludes changing
the representational identity in the returned ticket granting ticket.

Have a good day.

Greg

}-- End of excerpt from Sam Hartman

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg at enjellic.com
------------------------------------------------------------------------------
"After being a technician for 2 years, I've discovered if people took
care of their health with the same reckless abandon as their computers,
half would be at the kitchen table on the phone with the hospital, trying
to remove their appendix with a butter knife."
                                -- Brian Jones