Exposing authentication indicators through libkrb5

[Matt Rogers]

----- Original Message -----
> From: "Greg Hudson" <ghudson at mit.edu>
> To: "Matt Rogers" <mrogers at redhat.com>, krbdev at mit.edu
> 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