Exposing authentication indicators through libkrb5

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

Exposing authentication indicators through libkrb5

Matt Rogers
Hi,

In continuing the discussion about exposing AI data to GSSAPI name extension,
the AI authdata plugin will need to be able to acquire the raw authdata (after
extraction from a verified CAMMAC) with an indication that the contents were
authenticated. It seems that this processing will need to be done outside of the
plugin since it won't have access to the keys required to verify the CAMMAC.
What would be the correct way to have the CAMMAC pre-processed in order to
provide the plugin the raw authdata?

In addition to this, authind_extract() (which is currently private to the kdc
code) may need to be moved to libkrb5 so the plugin can handle the authdata.

Any input is appreciated.

Regards,

--
Matt Rogers
Red Hat, Inc
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Exposing authentication indicators through libkrb5

Greg Hudson
On 02/17/2016 10:06 AM, Matt Rogers wrote:
> In continuing the discussion about exposing AI data to GSSAPI name extension,
> the AI authdata plugin will need to be able to acquire the raw authdata (after
> extraction from a verified CAMMAC) with an indication that the contents were
> authenticated. It seems that this processing will need to be done outside of the
> plugin since it won't have access to the keys required to verify the CAMMAC.

Can you elaborate?  The current authdata verify method receives a key
parameter, which I believe is the key required to verify the CAMMAC
using the svc-verifier.

> In addition to this, authind_extract() (which is currently private to the kdc
> code) may need to be moved to libkrb5 so the plugin can handle the authdata.

Yes, some code currently in the KDC will need to be moved to libkrb5.
Assuming these won't be public APIs, use k5_ name prefixes for the new
library functions, declare them in include/k5-int.h, and add them to
lib/krb5/libkrb5.exports so the KDC can access them.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Exposing authentication indicators through libkrb5

Matt Rogers


----- Original Message -----

> From: "Greg Hudson" <[hidden email]>
> To: "Matt Rogers" <[hidden email]>, [hidden email]
> Sent: Wednesday, February 17, 2016 12:01:49 PM
> Subject: Re: Exposing authentication indicators through libkrb5
>
> On 02/17/2016 10:06 AM, Matt Rogers wrote:
> > In continuing the discussion about exposing AI data to GSSAPI name
> > extension,
> > the AI authdata plugin will need to be able to acquire the raw authdata
> > (after
> > extraction from a verified CAMMAC) with an indication that the contents
> > were
> > authenticated. It seems that this processing will need to be done outside
> > of the
> > plugin since it won't have access to the keys required to verify the
> > CAMMAC.
>
> Can you elaborate?  The current authdata verify method receives a key
> parameter, which I believe is the key required to verify the CAMMAC
> using the svc-verifier.
>

After looking at it more my concern is that leading up to calling the verify
function (in rd_req_decoded_opt()) the key provided could be a subkey or a
service key from the keytab, and we need to make sure we're only using the
service key to check the svc-verifier, without unnecessary trips to the keytab.  

> > In addition to this, authind_extract() (which is currently private to the
> > kdc
> > code) may need to be moved to libkrb5 so the plugin can handle the
> > authdata.
>
> Yes, some code currently in the KDC will need to be moved to libkrb5.
> Assuming these won't be public APIs, use k5_ name prefixes for the new
> library functions, declare them in include/k5-int.h, and add them to
> lib/krb5/libkrb5.exports so the KDC can access them.
>

I submitted PR #410 for two public API functions. They will first be needed
for a check_policy_tgs KDB method, but then also for the authdata plugin.
Thanks again.

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

Re: Exposing authentication indicators through libkrb5

Greg Hudson
On 02/22/2016 06:06 PM, Matt Rogers wrote:
> After looking at it more my concern is that leading up to calling the verify
> function (in rd_req_decoded_opt()) the key provided could be a subkey or a
> service key from the keytab, and we need to make sure we're only using the
> service key to check the svc-verifier, without unnecessary trips to the keytab.  

The keyblock we pass to krb5int_authdata_verify() is &decrypt_key, which
is always the key used to decrypt the ticket.  Perhaps the presence of
the user-to-user case is confusing because of the way it pulls a
keyblock from the auth context, but it's still setting decrypt_key to
the ticket encryption key.

> I submitted PR #410 for two public API functions. They will first be needed
> for a check_policy_tgs KDB method, but then also for the authdata plugin.
> Thanks again.

I'm not sure it's feasible to do auth indicator verification inside
check_policy_tgs, and these APIs don't seem to be applicable to that
task.  The KDC needs to use the KDC verifier to verify the CAMMAC, not
the service verifier, and check_policy_tgs does not receive either the
ticket decryption key or the service-realm local TGT entry.

Nathaniel brought this part of things up on IRC.  I gave an alternative
suggestion then, but I'm not sure it was read since I sent it late in
the day.  See the last two things here:

http://colabti.org/irclogger/irclogger_log/krbdev?date=2016-02-10
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev