keytab to krb5_creds?

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

keytab to krb5_creds?

John Hascall

It seems to me that one ought to be able to construct a
krb5_creds struct given a keytab (and the princ name you
want from it)?  [probably re-inventing a number of wheels
due to non-publically visible functions]

Is this correct?

John
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: keytab to krb5_creds?

Greg Hudson
On Fri, 2011-01-28 at 14:49 -0500, John Hascall wrote:
> It seems to me that one ought to be able to construct a
> krb5_creds struct given a keytab (and the princ name you
> want from it)?  [probably re-inventing a number of wheels
> due to non-publically visible functions]
>
> Is this correct?

The problem is not completely specified.  A keytab entry contains a
principal and a key (and some other stuff).  A krb5_creds struct
contains a client principal, a service principal, a ticket session key,
and a ticket (and some other stuff).

If you have a keytab entry for the principal P, then you can locally
construct C->P credentials for any client principal C.  We don't have
the library routines to make it easy, and you won't necessarily get the
authdata you want in the ticket, but it's possible without any
additional knowledge.

If you have a keytab entry for the principal P, you can contact the KDC
to get P->S principals for most service principals S.  This is a common
use case and is implemented by krb5_get_init_creds_keytab().  You can't
locally construct credentials like that because you don't know S's key.


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: keytab to krb5_creds?

John Hascall

> On Fri, 2011-01-28 at 14:49 -0500, John Hascall wrote:
> > It seems to me that one ought to be able to construct a
> > krb5_creds struct given a keytab (and the princ name you
> > want from it)?  [probably re-inventing a number of wheels
> > due to non-publically visible functions]

> > Is this correct?

> The problem is not completely specified.  A keytab entry contains a
> principal and a key (and some other stuff).  A krb5_creds struct
> contains a client principal, a service principal, a ticket session key,
> and a ticket (and some other stuff).

> If you have a keytab entry for the principal P, then you can locally
> construct C->P credentials for any client principal C.  We don't have
> the library routines to make it easy, and you won't necessarily get the
> authdata you want in the ticket, but it's possible without any
> additional knowledge.

> If you have a keytab entry for the principal P, you can contact the KDC
> to get P->S principals for most service principals S.  This is a common
> use case and is implemented by krb5_get_init_creds_keytab().  You can't
> locally construct credentials like that because you don't know S's key.

OK, more specific.  I have two processes on the same machine which
exchange data via a file.  Now this file is going to contain somewhat
sensitive info.  Both processes are already "kerberized", and have
access to a common keytab, so my thought was:
    krb5_mk_req+krb_mk_priv -> file -> krb5_rd_req+krb5_rd_priv.
However given the data in the file and access to the key from the keytab,
one could obviously reconstruct the sensitive data.  Unless the
key had since been changed.  So then I'm thinking about a rapidly
changing key and keytab.  Which lead me to think: these are the only two
things in the whole world which use this key -- why should the KDC
be involved at all?

Hence, my initial question.


John
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: keytab to krb5_creds?

Russ Allbery
In reply to this post by John Hascall
John Hascall <[hidden email]> writes:

> It seems to me that one ought to be able to construct a krb5_creds
> struct given a keytab (and the princ name you want from it)?  [probably
> re-inventing a number of wheels due to non-publically visible functions]

The kimpersonate tool that comes with Heimdal does essentially this.  Per
the man page:

     The kimpersonate program creates a "fake" ticket using the
     service-key of the service.  The service key can be read from a
     Kerberos 5 keytab, AFS KeyFile or (if compiled with support for
     Kerberos 4) a Kerberos 4 srvtab.

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: keytab to krb5_creds?

John Hascall


Thanks everyone for the hints.  Turns out it only took a
couple hundred lines of code to work up a Q+D functional
proof-of-concept.

John

-------------------------------------------------------------------------------
John Hascall, [hidden email]
Team Lead, NIADS (Network Infrastructure, Authentication & Directory Services)
IT Services, The Iowa State University of Science and Technology

> John Hascall <[hidden email]> writes:
>
> > It seems to me that one ought to be able to construct a krb5_creds
> > struct given a keytab (and the princ name you want from it)?  [probably
> > re-inventing a number of wheels due to non-publically visible functions]
>
> The kimpersonate tool that comes with Heimdal does essentially this.  Per
> the man page:
>
>      The kimpersonate program creates a "fake" ticket using the
>      service-key of the service.  The service key can be read from a
>      Kerberos 5 keytab, AFS KeyFile or (if compiled with support for
>      Kerberos 4) a Kerberos 4 srvtab.
>
> --
> Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
>

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: keytab to krb5_creds?

Brian Candler
In reply to this post by John Hascall
On Fri, Jan 28, 2011 at 02:09:14PM -0600, John Hascall wrote:

> OK, more specific.  I have two processes on the same machine which
> exchange data via a file.  Now this file is going to contain somewhat
> sensitive info.  Both processes are already "kerberized", and have
> access to a common keytab, so my thought was:
>     krb5_mk_req+krb_mk_priv -> file -> krb5_rd_req+krb5_rd_priv.
> However given the data in the file and access to the key from the keytab,
> one could obviously reconstruct the sensitive data.  Unless the
> key had since been changed.  So then I'm thinking about a rapidly
> changing key and keytab.  Which lead me to think: these are the only two
> things in the whole world which use this key -- why should the KDC
> be involved at all?

Well, the point of the KDC is that principal A can prove its identity to
principal B without knowing principal B's secret key (and vice versa). For
two entities with the same key, the KDC is indeed irrelevant.

If you're writing the data into a file, maybe just encrypting it with the
key from a "keytab" would be sufficient - e.g.  using gpg in symmetric mode
and read the passphrase from a file (or gpg with pub/priv key, reading the
priv key passphrase from a file).  As you say, anyone who can read the
keytab can also read the data, but that's going to be a fundamental
limitation of your design anyway.  Ultimately, each process is going to need
credentials suitable for decrypting data written by the other process,
otherwise it can't work, and it has to get those credentials from somewhere.

A few alternatives:

1. you store those secret info in the filesystem or in the application
itself (which makes it readable to anyone else with sufficient privileges)

2. you prompt for it when each process starts, and keep it in RAM (which
means restarts require manual intervention)

3. you have a parent-child relationship between the two processes: process A
can think of a random key, fork, and process B knows the same key. This also
keeps it in RAM only, but any existing files on disk will become useless if
you restart the processes.

4. you use some sort of hardware approach like TPM or a crypto module - but
even then, you have to make sure that only processes A/B can ask the module
to decrypt the data, which brings you back to the same problem. You could
perhaps run the two processes in separate VMs, and communicate via a shared
filesystem such as NFS.

5. does it really need to go via the filesystem? Could you use TLS over a
socket instead?

Just a few thoughts.

B.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: keytab to krb5_creds?

John Hascall


Well, I'm surely not claiming my approach here is particularly
general, but I'm working with a large system that's been around for
over 20 years, so it has accreted considerable mass and inertia.
It already uses kerberos, and the model:
   producer -> [circular file transaction buffer] -> consumers
is fixed.  So, the fact that I can do what I need in 100 lines
of code or so on each end, and come up with it in less than a
day is a good thing.


John


> If you're writing the data into a file, maybe just encrypting it with the
> key from a "keytab" would be sufficient - e.g.  using gpg in symmetric mode
> and read the passphrase from a file (or gpg with pub/priv key, reading the
> priv key passphrase from a file).  As you say, anyone who can read the
> keytab can also read the data, but that's going to be a fundamental
> limitation of your design anyway.  Ultimately, each process is going to need
> credentials suitable for decrypting data written by the other process,
> otherwise it can't work, and it has to get those credentials from somewhere.
>
> A few alternatives:
>
> 1. you store those secret info in the filesystem or in the application
> itself (which makes it readable to anyone else with sufficient privileges)
>
> 2. you prompt for it when each process starts, and keep it in RAM (which
> means restarts require manual intervention)
>
> 3. you have a parent-child relationship between the two processes: process A
> can think of a random key, fork, and process B knows the same key. This also
> keeps it in RAM only, but any existing files on disk will become useless if
> you restart the processes.
>
> 4. you use some sort of hardware approach like TPM or a crypto module - but
> even then, you have to make sure that only processes A/B can ask the module
> to decrypt the data, which brings you back to the same problem. You could
> perhaps run the two processes in separate VMs, and communicate via a shared
> filesystem such as NFS.
>
> 5. does it really need to go via the filesystem? Could you use TLS over a
> socket instead?
>
> Just a few thoughts.
>
> B.
>

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos