Using authentication indicators

[Ken Hornstein]

For some context, we are using PKINIT with smartcards in our Kerberos
deployment and we are using the value of the HW_AUTH ticket flag to
make authorization decisions on application servers (not everyone uses
a smartcard in our deployment, sometimes you might not have a smartcard
for various reasons, it's not required for all services).  To complicate
matters further there is also the option of using one or more types of
one-time hardware tokens instead of a smartcart.  The current HW_AUTH
ticket flag is not exactly very flexible so I have been investigating
the use of authentication indicators as an alternative to make more
intelligent authorization decisions.  I am trying to think ahead and
give us the flexibility to make decisions like, "You can use any type
of hardware token to access this resource" or "you HAVE to use this one
type of hardware token to do particular things with this resource".
This is a medium to long term effort for us so I'd rather get this all
right the first time.

Right now it seems like there are two barriers to deploying this in
practice.

- There does not seem to be a public krb5 API to decode authentication
  indicators.  I mean, yes, you can look at the authorization data
  in the ticket but authentication indicators are wrapped in a CAMMAC
  container and it doesn't seem like any of the public APIs actually
  support decoding that.  Yes, I mean, I suppose it's possible that I
  could manually verify the CAMMAC container using the key from the
  keytab but that seems crazy when there is already code in the
  krb5 library that does that.

  I am aware that there is a GSSAPI extension that lets one extract
  that information; without getting into another long discussion about
  the GSSAPI vs the krb5 API, I do have a bunch of native krb5 applications
  and that's not about to change anytime soon, so just using the GSSAPI
  isn't an option for me right now (of course, I'm fine using those
  GSSAPI functions for our GSSAPI applications).

  It _does_ seem that the functions krb5_authdata_get_attribute_types()
  and krb5_authdata_get_attribute() do what I would need, and actually
  are already exported and exist to provide this functionality to the
  GSSAPI.  But I see that they take a "krb5_authdata_context" and
  if you made those public you'd probably need to include the
  authdata_context functions as well; maybe that isn't the right API.
  Also, I'm a little unclear on how the authdata_context has access to
  the authentication indicators from the AP-REQ!  I mean, I am sure that
  it is happening, I just can't see HOW it happens.  I am sure I am missing
  something obvious here.  Anyway, if there IS a public native krb5 API
  function that lets you extract authentication indicators, I'm glad to
  use it; I'd just need to know which one to use.  If there isn't, could
  one be added?

- As previously discussed, authentication indicators are not passed
  through when using cross-realm authentication, and that's an issue
  for us as we make use of cross-realm authentication (ticket flags
  ARE passed through cross-realm, but I realize when that decision
  was made it was a simpler time).  I'm wondering what the options are
  here.   I'm glad to write code and submit code that lets one configure
  on their KDC to accept authentication indicators when using cross-realm,
  but I am wondering what would be acceptable.  Are people thinking of
  something that would be, "I accept any authentication indicators
  from this realm", or "I only accept this list of authentication
  indicators from this realm", or something else?  I'm open to any ideas
  here.

--Ken