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,

[Greg Hudson]

Post by Matt Rogers
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.

Post by Matt Rogers
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Matt Rogers]

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

Sent: Wednesday, February 17, 2016 12:01:49 PM
Subject: Re: Exposing authentication indicators through libkrb5

Post by Matt Rogers
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.

Post by Matt Rogers
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

Post by Matt Rogers
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.

Post by Matt Rogers
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev