pkinit and krb5.conf [appdefaults] section

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

pkinit and krb5.conf [appdefaults] section

Matthew Andrews-2
Hi,

While setting up krb5.conf for pkinit I was reminded of a recent
discussion in the thread titled "Re: Turning off hostname
canonicalisation" about what sort of things should end up in the
[appdefaults] section. I noticed the "pkinit-anchors =
OPENSSL-ANCHOR-DIR:/dir-to-client-trusted-ca-hashes" in the
[appdefaults] section. Is this used directly by kinit, or is it parsed
by the libs? If this is entirely parsed by kinit, does that mean that
any app designed to acquire credentials via the pkinit mechanism would
have to parse this(or a similar directive) manually? I'm thinking about
a pam module here(something that I may be looking into working on in the
near future.)

also if this is parsed by the client libs shouldn't it go into
[libdefaults]?

should this be coordinated with mit krbdev so that if/when they
implement some form of pkinit we don't wind up with 2 ways of doing
things? If this has all been discussed before I joined the list then I
appologize for not checking for archives.

-Matt
Reply | Threaded
Open this post in threaded view
|

Re: pkinit and krb5.conf [appdefaults] section

Douglas E. Engert


Matthew Andrews wrote:

> Hi,
>
> While setting up krb5.conf for pkinit I was reminded of a recent
> discussion in the thread titled "Re: Turning off hostname
> canonicalisation" about what sort of things should end up in the
> [appdefaults] section. I noticed the "pkinit-anchors =
> OPENSSL-ANCHOR-DIR:/dir-to-client-trusted-ca-hashes" in the
> [appdefaults] section. Is this used directly by kinit, or is it parsed
> by the libs? If this is entirely parsed by kinit, does that mean that
> any app designed to acquire credentials via the pkinit mechanism would
> have to parse this(or a similar directive) manually? I'm thinking about
> a pam module here(something that I may be looking into working on in the
> near future.)

For PAM PKINIT mods see:
http://www.stacken.kth.se/lists/heimdal-discuss/2005-05/msg00009.html

That has mods to the RedHat pam_krb5-1.3-rc7 to work with PKINIT.
and have a pam.conf for GDM. These where designed to work with a smartcard.


>
> also if this is parsed by the client libs shouldn't it go into
> [libdefaults]?
>
> should this be coordinated with mit krbdev so that if/when they
> implement some form of pkinit we don't wind up with 2 ways of doing
> things? If this has all been discussed before I joined the list then I
> appologize for not checking for archives.

Yes.

>
> -Matt
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
Reply | Threaded
Open this post in threaded view
|

Re: pkinit and krb5.conf [appdefaults] section

Love Hörnquist Åstrand
In reply to this post by Matthew Andrews-2

Matthew Andrews <[hidden email]> writes:

> Hi,
>
> While setting up krb5.conf for pkinit I was reminded of a recent
> discussion in the thread titled "Re: Turning off hostname
> canonicalisation" about what sort of things should end up in the
> [appdefaults] section. I noticed the "pkinit-anchors =
> OPENSSL-ANCHOR-DIR:/dir-to-client-trusted-ca-hashes" in the
> [appdefaults] section. Is this used directly by kinit, or is it parsed
> by the libs? If this is entirely parsed by kinit, does that mean that
> any app designed to acquire credentials via the pkinit mechanism would
> have to parse this(or a similar directive) manually? I'm thinking
> about a pam module here(something that I may be looking into working
> on in the near future.)
They are today only onderstod by kinit, but I guess that code can be moved
to krb5_get_init_creds_opt_set_pkinit() in case NULL is passed in.

> also if this is parsed by the client libs shouldn't it go into
> [libdefaults]?

The whole file is parsed by krb5 library. The reason I used appdefault is
that the krb5_appdefault_string() function takes a realm element, so you
can have diffrent trust anchors per realm.

> should this be coordinated with mit krbdev so that if/when they
> implement some form of pkinit we don't wind up with 2 ways of doing
> things? If this has all been discussed before I joined the list then I
> appologize for not checking for archives.

Maybe it should, but so far I'm not sure this is the way to do it, we are
still testing what works good and is easy to configure.

Love


attachment0 (487 bytes) Download Attachment