Extending certauth plugin to set ticket flags?

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

Extending certauth plugin to set ticket flags?

Ken Hornstein
For a while we've been maintaining our own PKINIT plugin because of some
needs we have in our environment.  The three things that it does that
were not always supported by MIT Kerberos are:

1) Matching of the client principal to the subject DN of the certificate
2) OCSP revocation checking of the client certificate
3) Setting of the TKT_FLG_HW_AUTH flag in the TGT if the certificate had
   had some specific policies.

1) is now implemented via MIT Kerberos for a while, and I recently discovered
the certauth plugin which would be a perfect place to implement 2).  But
I am not sure of a way to implement 3) without a whole new PKINIT plugin.
And to be honest, I sure would love being out of the business of maintaining
our own pkinit plugin.

I see that the certauth plugin can set authentication indicators, but
that's just KRB5_AUTHDATA and we have a lot of our infrastructure that
uses TKT_FLG_HW_AUTH now and that would be hard to change.  I am wondering
if it would be possible to extend the certauth plugin to allow the setting
of TKT_FLG_HW_AUTH?  What that API would look like, I have no particular
preference.  I am not sure it makes sense to pass down the whole
encrypted ticket reply down to certauth function, but that would be
easy.  A returned boolean or callback to tell the pkinit plugin to set
HW_AUTH would also be sufficient.  Really, I don't care about the API
all that much; all I need is access to the certificate to check the
policy information.  certauth seems the obvious existing plugin interface
to check for that.

Thoughts?

--Ken
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Extending certauth plugin to set ticket flags?

Greg Hudson
On 2/17/20 9:20 PM, Ken Hornstein wrote:
> 3) Setting of the TKT_FLG_HW_AUTH flag in the TGT if the certificate had
>    had some specific policies.

I thought of two ways to retrofit this capability with a low code footprint:

1. Designate a magic error code for the certauth authorize() method.
The code would mean "yes the cert is authorized for this client, and
also please set the hw-authent ticket flag".

2. Designate a magic authentication indicator value (probably "hwauth").
 In the core KDC code near the end of AS-REQ processing, check if this
indicator is asserted and set the hw-authent bit.

The second approach fits with the notion that the hw-authent bit is a
legacy special case of auth indicators, and it covers any interface
which can assert auth indicators (certauth, kdcpreauth, KDB
sign_authdata()).  However, it does make an inroad into the auth
indicator namespace, which is currently entirely site-defined.  Also,
tickets issued this way would be slightly larger than tickets issued
with just the hw-authent bit set, since they would also contain the
authorization data asserting the auth indicator.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Extending certauth plugin to set ticket flags?

Ken Hornstein
>2. Designate a magic authentication indicator value (probably "hwauth").
> In the core KDC code near the end of AS-REQ processing, check if this
>indicator is asserted and set the hw-authent bit.

I'd be happy with this.  I agree with you that it does fit in the notion
that hw-authent is legacy, and it provides a reasonable transition
strategy since it's clear that auth indicators make more long-term sense
for application servers to use (since for a transition period you'd need
to do both the hw-authent flag and an auth indicator).  It does occur
to me that if you were concerned about enroaching into the site-defined
auth data namespace, you could create a KDC configuration option that
says "Set the HW-AUTH flag if this auth indicator is set".  That would
be a slightly larger code footprint, though.  Either case (a hard-coded
magic auth indicator, or a configurable one) would be perfect.

--Ken
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Extending certauth plugin to set ticket flags?

Greg Hudson
On 2/18/20 6:33 PM, Ken Hornstein wrote:
>> 2. Designate a magic authentication indicator value (probably "hwauth").
>> In the core KDC code near the end of AS-REQ processing, check if this
>> indicator is asserted and set the hw-authent bit.
>
> I'd be happy with this.

Unfortunately, this approach turns out to be difficult to implement
properly.  (Authdata handling happens late in the AS-REQ process, and
can affect the set of indicators.  Checking the server principal's
hardware authentication requirement against the ticket flags happens
earlier, and if that check fails, we have to produce a hint list, which
is an async process, so it's not easy to move the check later.)

So I will probably go with the designated authorize() return code, if
that meets the requirements.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Extending certauth plugin to set ticket flags?

Ken Hornstein
>>> 2. Designate a magic authentication indicator value (probably "hwauth").
>>> In the core KDC code near the end of AS-REQ processing, check if this
>>> indicator is asserted and set the hw-authent bit.
>>
>> I'd be happy with this.
>
>Unfortunately, this approach turns out to be difficult to implement
>properly.  (Authdata handling happens late in the AS-REQ process, and
>can affect the set of indicators.  Checking the server principal's
>hardware authentication requirement against the ticket flags happens
>earlier, and if that check fails, we have to produce a hint list, which
>is an async process, so it's not easy to move the check later.)

Well, I will defer to your knowledge of the KDC AS-REQ processing path,
and "perfect is the enemy of the good" and all that.  If you are fine
with a designated authorize_cert return code, then so am I.

--Ken
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Extending certauth plugin to set ticket flags?

Greg Hudson
On 2/21/20 1:11 PM, Ken Hornstein wrote:
> Well, I will defer to your knowledge of the KDC AS-REQ processing path,
> and "perfect is the enemy of the good" and all that.  If you are fine
> with a designated authorize_cert return code, then so am I.

Does your custom PKINIT module set the PA_HARDWARE flag in
pkinit_server_get_flags()?  That would be necessary to make PKINIT work
with client principals flagged with +requires_hwauth, but perhaps you're
not doing that.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Extending certauth plugin to set ticket flags?

Ken Hornstein
>Does your custom PKINIT module set the PA_HARDWARE flag in
>pkinit_server_get_flags()?  That would be necessary to make PKINIT work
>with client principals flagged with +requires_hwauth, but perhaps you're
>not doing that.

The answer is ... yes.  Ah, crud, I had forgotten about that.  Perhaps
the right solution there is to create a configuration option in
krb5.conf/kdc.conf that will tell pkinit to set that?

--Ken

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Extending certauth plugin to set ticket flags?

Greg Hudson
On 2/22/20 9:07 AM, Ken Hornstein wrote:
>> Does your custom PKINIT module set the PA_HARDWARE flag in
>> pkinit_server_get_flags()?  That would be necessary to make PKINIT work
>> with client principals flagged with +requires_hwauth, but perhaps you're
>> not doing that.
>
> The answer is ... yes.  Ah, crud, I had forgotten about that.  Perhaps
> the right solution there is to create a configuration option in
> krb5.conf/kdc.conf that will tell pkinit to set that?

That would work, but I'd rather not add a config option for this
feature.  Ever config option adds to the oversized bin of config options
that every administrator has to sort through in the documentation.
(Having undocumented config options isn't great either.)

The simplest option is to make PKINIT always set PA_HARDWARE, with a
comment.  The risk of breaking any deployments with this change seems
low, since PKINIT readily configures itself out on either the KDC and
the client, and not many deployments use +requires_hwauth or the
hw-authent flag.

More surgically, PKINIT could only set PA_HARDWARE when a certauth
module might set hw-authent (we'd have to make some tweak to the
certauth changes to make it possible to tell this at initialization
time).  Unfortunately, that option doesn't work, because the kdcpreauth
flags() method doesn't take a moddata argument.

I did notice that when the client principal has +requires_hwauth and
PKINIT doesn't set the hw-authent flag, the result is a preauth loop
(terminating with "Looping detected inside krb5_get_in_tkt").  It's
unclear what piece of code should change to prevent this, if any.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Extending certauth plugin to set ticket flags?

Ken Hornstein
>That would work, but I'd rather not add a config option for this
>feature.  Ever config option adds to the oversized bin of config options
>that every administrator has to sort through in the documentation.
>(Having undocumented config options isn't great either.)

I understand where you're coming from; I am really flexible here.
If you are happy with PKINIT always setting PA_HARDWARE then so am I.

I understand this is a weird mix of old and new code and the older-style
authentication indicators like TKT_FLG_HW_AUTH; my goal here is to
get our community on a long-term sustainable path in terms of code
maintenance.  Getting from here to there isn't always easy.

>I did notice that when the client principal has +requires_hwauth and
>PKINIT doesn't set the hw-authent flag, the result is a preauth loop
>(terminating with "Looping detected inside krb5_get_in_tkt").  It's
>unclear what piece of code should change to prevent this, if any.

Ah, yes, I know that error well :-/

--Ken
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev