[19361] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: Exposing authentication indicators through libkrb5

daemon@ATHENA.MIT.EDU (Matt Rogers)
Mon Feb 22 18:07:01 2016

Date: Mon, 22 Feb 2016 18:06:44 -0500 (EST)
From: Matt Rogers <mrogers@redhat.com>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <389598777.23125135.1456182404752.JavaMail.zimbra@redhat.com>
In-Reply-To: <56C4A77D.3000504@mit.edu>
MIME-Version: 1.0
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu



----- Original Message -----
> From: "Greg Hudson" <ghudson@mit.edu>
> To: "Matt Rogers" <mrogers@redhat.com>, krbdev@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
_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post