Using a master key and principal name to derive password for principal

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

Using a master key and principal name to derive password for principal

Coe Ts7
Hi,
I'm look for a simple but effective High Available solution for kerberos.
In my deployment, I will use kerberos PKINIT. So there's a chance that the kerberos doesn't store principal list, just generate ticket according the name in PKI certificate.
And I try to go further and make kerberos not to store principal password, so that the kerberos is completely stateless and fully trusts PKI.
To achieve that,  I want to use some crypto & hashing mechanisms to make all kerberos instances could calculate the same password for each principal through a shared master key and principal name.

I'm wondering is this way secure cryptographically? If so, is there some source code for reference to make this algorithm implemented?
Thanks in advance!

Regards,
tm3y
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

回复: Using a master key and principal name to derive password for principal

Coe Ts7
Maybe use something like  HMAC(secret_key, principal_name) or PBKDF2(HMAC(master_secret_key, principal_name))(kerberos will do PBKDF2) as the principals' password,
Then I delivery the dervied passwords to the correspond principals. Then kerberos could authenticate the user with only a single maseter_secret_key.
Is this secure?

Regards,
tm3y
________________________________
发件人: Coe Ts7
发送时间: 2019年10月15日 3:46
收件人: [hidden email] <[hidden email]>
主题: Using a master key and principal name to derive password for principal

Hi,
I'm look for a simple but effective High Available solution for kerberos.
In my deployment, I will use kerberos PKINIT. So there's a chance that the kerberos doesn't store principal list, just generate ticket according the name in PKI certificate.
And I try to go further and make kerberos not to store principal password, so that the kerberos is completely stateless and fully trusts PKI.
To achieve that,  I want to use some crypto & hashing mechanisms to make all kerberos instances could calculate the same password for each principal through a shared master key and principal name.

I'm wondering is this way secure cryptographically? If so, is there some source code for reference to make this algorithm implemented?
Thanks in advance!

Regards,
tm3y
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Using a master key and principal name to derive password for principal

Roland C. Dowdeswell
In reply to this post by Coe Ts7
On Tue, Oct 15, 2019 at 03:46:25AM +0000, Coe Ts7 wrote:
>

> I'm look for a simple but effective High Available solution for kerberos.
> In my deployment, I will use kerberos PKINIT. So there's a chance
> that the kerberos doesn't store principal list, just generate ticket
> according the name in PKI certificate.
> And I try to go further and make kerberos not to store principal
> password, so that the kerberos is completely stateless and fully
> trusts PKI.
> To achieve that,  I want to use some crypto & hashing mechanisms
> to make all kerberos instances could calculate the same password
> for each principal through a shared master key and principal name.

I've done something like this in Heimdal, although it is in the
early stages and I haven't finished writing up the documentation
for it.  But it's for a very different use case than that which
you are describing, namely it's for ultra-fast provisioning of
Kerberos services where the KDC doesn't even to know what service
principals are in use in advance.

You use case sounds quite different.  From what I read above, I
get the impression that you are interested in using PKI for clients
who will use PKINIT to obtain a TGT.  In this case, is there any
reason that you need to know the client's key or password?  If you
never need to know a key or a password, then just randomise the
key and forget it on the creation of the client principal.

The only reason to generate predictable keys for principals is if
you intend to use them without PKINIT and need to be able to generate
the key.  Is there are reason that you need the keys to be predictable?

--
    Roland C. Dowdeswell                   http://Imrryr.ORG/~elric/
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Using a master key and principal name to derive password for principal

Coe Ts7
> get the impression that you are interested in using PKI for clients
> who will use PKINIT to obtain a TGT.  In this case, is there any
> reason that you need to know the client's key or password?  If you
> never need to know a key or a password, then just randomise the
> key and forget it on the creation of the client principal.

Thanks for the reply.
The reason why I need the keys to be predictable is that I don't want kerberos to store anything,
to make kerberos stateless. And a stateless server is more friendly to achieve a goal of High Availability architecture.
For master-slave architecture of krb5, manual slave to master promotion and traffic redirection must be made
if the old master instance down. But if I make kerberos fully stateless(store nothing), then multi kdc instances and
simple retry strategy on client-side will achieve fully high availability.

Now I'm planing to use krb5_c_string_to_key(https://github.com/krb5/krb5/blob/master/src/lib/crypto/krb/string_to_key.c#L31)
with master_secret_key as the password argument and principal_realm_name as the salt argument.
It seems that if a function is a PRF(pseudorandom function), then the function is safe to generate password.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Using a master key and principal name to derive password for principal

Roland C. Dowdeswell
On Wed, Oct 16, 2019 at 02:45:19AM +0000, Coe Ts7 wrote:
>

>    > get the impression that you are interested in using PKI for clients
>
>    > who will use PKINIT to obtain a TGT.  In this case, is there any
>    > reason that you need to know the client's key or password?  If you
>    > never need to know a key or a password, then just randomise the
>    > key and forget it on the creation of the client principal.
>    Thanks for the reply.
>    The reason why I need the keys to be predictable is that I don't want
>    kerberos to store anything,

I understand that.

What I am asking is: do you actually need the principals to have
keys that you can predict?  What are you going to use the keys for?
If you are simply going to have PKINIT clients, then you do not
need to _know_ the keys.  And if you do not need to know the keys,
then it is sufficient to randomise them.  You will still want to
have an entry in the Kerberos DB in most cases because it may contain
ancilliary data such as the existence of the name.

When I say, "What are you going to use the keys for?", the question
really is made up of two parts:

        1.  what AS_REQs do you expect to issue and serve for the
            principal in question? and

        2.  what TGS_REQs do you expect to issue and serve for the
            principal in question?

--
    Roland C. Dowdeswell                   http://Imrryr.ORG/~elric/
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Using a master key and principal name to derive password for principal

Coe Ts7
> do you actually need the principals to have keys that you can predict?

I want to have the key to be predictable only on the KDC side, and the only purpose is
to make KDC stateless(store nothing). The keys are used only internally in kerberos.
keys are distributed automatically by kerberos, and no anther party has the need to know
the keys, nor be able to predict the keys.

> You will still want to have an entry in the Kerberos DB in most cases because it may
contain ancilliary data such as the existence of the name

A krb DB is essential, but I'm thinking a workaround for this: using a dummy DB plugin
(by modifing the offical kdb_db2 plugin), which will return dynamically generated principal
record when KDC querying a principal info. The db file on disk may only store admin principals.
I've done some demo code on kdb_db2 plugin, which will read a template principal from db,
then modify the princ/key_data field of the template entry, and return it to KDC. Not sure
if this could work.

Regards,
tm3y
________________________________
From: Roland C. Dowdeswell <[hidden email]>
Sent: Wednesday, October 16, 2019 16:04
To: Coe Ts7 <[hidden email]>
Cc: [hidden email] <[hidden email]>
Subject: Re: Using a master key and principal name to derive password for principal

On Wed, Oct 16, 2019 at 02:45:19AM +0000, Coe Ts7 wrote:
>

>    > get the impression that you are interested in using PKI for clients
>
>    > who will use PKINIT to obtain a TGT.  In this case, is there any
>    > reason that you need to know the client's key or password?  If you
>    > never need to know a key or a password, then just randomise the
>    > key and forget it on the creation of the client principal.
>    Thanks for the reply.
>    The reason why I need the keys to be predictable is that I don't want
>    kerberos to store anything,

I understand that.

What I am asking is: do you actually need the principals to have
keys that you can predict?  What are you going to use the keys for?
If you are simply going to have PKINIT clients, then you do not
need to _know_ the keys.  And if you do not need to know the keys,
then it is sufficient to randomise them.  You will still want to
have an entry in the Kerberos DB in most cases because it may contain
ancilliary data such as the existence of the name.

When I say, "What are you going to use the keys for?", the question
really is made up of two parts:

        1.  what AS_REQs do you expect to issue and serve for the
            principal in question? and

        2.  what TGS_REQs do you expect to issue and serve for the
            principal in question?

--
    Roland C. Dowdeswell                   http://Imrryr.ORG/~elric/
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Using a master key and principal name to derive password for principal

Alexander Bokovoy
On ke, 16 loka 2019, Ts7 Coe wrote:
>> do you actually need the principals to have keys that you can predict?
>
>I want to have the key to be predictable only on the KDC side, and the only purpose is
>to make KDC stateless(store nothing). The keys are used only internally in kerberos.
>keys are distributed automatically by kerberos, and no anther party has the need to know
>the keys, nor be able to predict the keys.
PKINIT doesn't rely on Kerberos principal keys at all. None of the
principal's keys are used for TGT key creation. So you don't need to
have those keys at place.

>
>> You will still want to have an entry in the Kerberos DB in most cases because it may
>contain ancilliary data such as the existence of the name
>
>A krb DB is essential, but I'm thinking a workaround for this: using a dummy DB plugin
>(by modifing the offical kdb_db2 plugin), which will return dynamically generated principal
>record when KDC querying a principal info. The db file on disk may only store admin principals.
>I've done some demo code on kdb_db2 plugin, which will read a template principal from db,
>then modify the princ/key_data field of the template entry, and return it to KDC. Not sure
>if this could work.
Try to not set entry.key_data and entry.n_key_data (where entry is
krb5_db_entry structure) fields. We do this in FreeIPA for principals
that have no key associated and it works for PKINIT. It works just fine.


>
>Regards,
>tm3y
>________________________________
>From: Roland C. Dowdeswell <[hidden email]>
>Sent: Wednesday, October 16, 2019 16:04
>To: Coe Ts7 <[hidden email]>
>Cc: [hidden email] <[hidden email]>
>Subject: Re: Using a master key and principal name to derive password for principal
>
>On Wed, Oct 16, 2019 at 02:45:19AM +0000, Coe Ts7 wrote:
>>
>
>>    > get the impression that you are interested in using PKI for clients
>>
>>    > who will use PKINIT to obtain a TGT.  In this case, is there any
>>    > reason that you need to know the client's key or password?  If you
>>    > never need to know a key or a password, then just randomise the
>>    > key and forget it on the creation of the client principal.
>>    Thanks for the reply.
>>    The reason why I need the keys to be predictable is that I don't want
>>    kerberos to store anything,
>
>I understand that.
>
>What I am asking is: do you actually need the principals to have
>keys that you can predict?  What are you going to use the keys for?
>If you are simply going to have PKINIT clients, then you do not
>need to _know_ the keys.  And if you do not need to know the keys,
>then it is sufficient to randomise them.  You will still want to
>have an entry in the Kerberos DB in most cases because it may contain
>ancilliary data such as the existence of the name.
>
>When I say, "What are you going to use the keys for?", the question
>really is made up of two parts:
>
>        1.  what AS_REQs do you expect to issue and serve for the
>            principal in question? and
>
>        2.  what TGS_REQs do you expect to issue and serve for the
>            principal in question?
>
>--
>    Roland C. Dowdeswell                   http://Imrryr.ORG/~elric/
>_______________________________________________
>krbdev mailing list             [hidden email]
>https://mailman.mit.edu/mailman/listinfo/krbdev

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Using a master key and principal name to derive password for principal

Roland C. Dowdeswell
In reply to this post by Coe Ts7
On Wed, Oct 16, 2019 at 09:32:17AM +0000, Ts7 Coe wrote:
>

> > do you actually need the principals to have keys that you can
> predict?

>   I want to have the key to be predictable only on the KDC side,
>   and the only purpose is to make KDC stateless(store nothing).
>   The keys are used only internally in kerberos.  keys are
>   distributed automatically by kerberos, and no anther party has
>   the need to know the keys, nor be able to predict the keys.

Then you don't actually need keys at all.  If no one is going to
make an AS_REQ or TGS_REQ with the principal as a target, then you
do not need keys.

That said, what you want is possible in Heimdal out of the box:

https://github.com/heimdal/heimdal/wiki/Setting-up-PK-INIT-and-Certificates

You will still need to maintain service principals and their keys,
though.

>    > You will still want to have an entry in the Kerberos DB in most cases
>    because it may
>
>    contain ancilliary data such as the existence of the name
>
>    A krb DB is essential, but I'm thinking a workaround for this: using a
>    dummy DB plugin
>
>    (by modifing the offical kdb_db2 plugin), which will return dynamically
>    generated principal
>
>    record when KDC querying a principal info. The db file on disk may only
>    store admin principals.
>
>    I've done some demo code on kdb_db2 plugin, which will read a
>    template principal from db,
>
>    then modify the princ/key_data field of the template entry, and return
>    it to KDC. Not sure
>
>    if this could work.
>
>    Regards,
>    tm3y
>      __________________________________________________________________
>
>    From: Roland C. Dowdeswell <[hidden email]>
>    Sent: Wednesday, October 16, 2019 16:04
>    To: Coe Ts7 <[hidden email]>
>    Cc: [hidden email] <[hidden email]>
>    Subject: Re: Using a master key and principal name to derive password
>    for principal
>
>    On Wed, Oct 16, 2019 at 02:45:19AM +0000, Coe Ts7 wrote:
>    >
>    >    > get the impression that you are interested in using PKI for
>    clients
>    >
>    >    > who will use PKINIT to obtain a TGT.  In this case, is there any
>    >    > reason that you need to know the client's key or password?  If
>    you
>    >    > never need to know a key or a password, then just randomise the
>    >    > key and forget it on the creation of the client principal.
>    >    Thanks for the reply.
>    >    The reason why I need the keys to be predictable is that I don't
>    want
>    >    kerberos to store anything,
>    I understand that.
>    What I am asking is: do you actually need the principals to have
>    keys that you can predict?  What are you going to use the keys for?
>    If you are simply going to have PKINIT clients, then you do not
>    need to _know_ the keys.  And if you do not need to know the keys,
>    then it is sufficient to randomise them.  You will still want to
>    have an entry in the Kerberos DB in most cases because it may contain
>    ancilliary data such as the existence of the name.
>    When I say, "What are you going to use the keys for?", the question
>    really is made up of two parts:
>            1.  what AS_REQs do you expect to issue and serve for the
>                principal in question? and
>            2.  what TGS_REQs do you expect to issue and serve for the
>                principal in question?
>    --
>        Roland C. Dowdeswell                   [1]http://Imrryr.ORG/~elric/
>
> References
>
>    1. http://Imrryr.ORG/~elric/


--
    Roland C. Dowdeswell                   http://Imrryr.ORG/~elric/
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Using a master key and principal name to derive password for principal

Coe Ts7
In reply to this post by Alexander Bokovoy
> Then you don't actually need keys at all. If no one is going to
make an AS_REQ or TGS_REQ with the principal as a target, then you
do not need keys.

The principals will authenticate with each other, so any principal could
be a target of TGS_REQ. So I thinks there still must be keys for every
principal?

> Try to not set entry.key_data and entry.n_key_data (where entry is
krb5_db_entry structure) fields. We do this in FreeIPA for principals
that have no key associated and it works for PKINIT. It works just fine.

I thinks this operation is identical with purgekeys command? Then it could
also make the principal unable to be a server role.

I think principal still need keys in my scenario.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Using a master key and principal name to derive password for principal

Alexander Bokovoy
On ke, 16 loka 2019, Ts7 Coe wrote:
>> Then you don't actually need keys at all. If no one is going to make
>> an AS_REQ or TGS_REQ with the principal as a target, then you do not
>> need keys.
>
>The principals will authenticate with each other, so any principal could
>be a target of TGS_REQ. So I thinks there still must be keys for every
>principal?

Yes, for server principals. Are you planning to use PKINIT-enabled users
to authenticate to each other? Typically, PKINIT is used for non-target
principals.

>> Try to not set entry.key_data and entry.n_key_data (where entry is
>> krb5_db_entry structure) fields. We do this in FreeIPA for principals
>> that have no key associated and it works for PKINIT. It works just
>> fine.
>
>I thinks this operation is identical with purgekeys command? Then it could
>also make the principal unable to be a server role.

In our cases users aren't server principals. The operation is not really a
'purgekeys' -- we simply set no Kerberos keys when creating users. So you'd
have something like

$ kinit admin
$ ipa user-add some-user
$ openssl req -new -newkey rsa:2048 -days 365 -nodes -keyout private.key -out cert.csr -subj '/CN=some-user'
$ ipa cert-request cert.csr --principal=some-user --profile-id=caIPAuserCert
$ ipa user-show some-user --out=cert.out

and then you can auth as that user

$ kinit -X X509_user_identity=FILE:./cert.out,private.key some-user
$ klist
Ticket cache: KEYRING:persistent:0:krb_ccache_hTd5xt5
Default principal: [hidden email]

Valid starting     Expires            Service principal
10/16/19 12:09:13  10/17/19 12:09:12  krbtgt/[hidden email]

User principal has no password or Kerberos keys on the account:

$ ipa user-show some-user | egrep '(Password|Kerberos)'
  Password: False
  Kerberos keys available: False

Practically, this will not work with server principals, of course.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Using a master key and principal name to derive password for principal

Roland C. Dowdeswell
In reply to this post by Coe Ts7
On Wed, Oct 16, 2019 at 10:33:29AM +0000, Ts7 Coe wrote:
>

>    > Then you don't actually need keys at all. If no one is going to
>
>    make an AS_REQ or TGS_REQ with the principal as a target, then you
>    do not need keys.
>
>    The principals will authenticate with each other, so any principal
>    could be a target of TGS_REQ. So I thinks there still must be keys
>    for every principal?

How will the principals know their keys?

--
    Roland C. Dowdeswell                   http://Imrryr.ORG/~elric/
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Using a master key and principal name to derive password for principal

Coe Ts7
I thought when using PKINIT, KDC will send the symmetric key to principal,
maybe encrypted with the public key. Looks like this isn't true in kerberos.
So I must deliver the symmetric key using outbound connection.
If so, in my scenario, principal act both client and server, PKINIT seems
unnecessary, and keytab file seems more suitable. But the approach I
described should still work.

There is one major problem to use principal name derived password:
If one principal get compromised, changing the master key could lead to
all principals' key changed. But this could be resolved by inserting the
compromised principal into the database with a new key.

Thank @Roland and @Alexander for the kind help on this issue.
Also, I have another simple and quick question. In freeipa or active directory,
Is that all service principals don't change their symmetric key in the entire
life time if no compromise occurred?
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Using a master key and principal name to derive password for principal

Alexander Bokovoy
On ke, 16 loka 2019, Ts7 Coe wrote:
>I thought when using PKINIT, KDC will send the symmetric key to principal,
>maybe encrypted with the public key. Looks like this isn't true in kerberos.
RFC 4556 defines the way how client and KDC pre-authenticate with
PKINIT.

>So I must deliver the symmetric key using outbound connection.
>If so, in my scenario, principal act both client and server, PKINIT seems
>unnecessary, and keytab file seems more suitable. But the approach I
>described should still work.
>
>There is one major problem to use principal name derived password:
>If one principal get compromised, changing the master key could lead to
>all principals' key changed. But this could be resolved by inserting the
>compromised principal into the database with a new key.
It is way better to have a state and store keys. ;)

>Thank @Roland and @Alexander for the kind help on this issue.
>Also, I have another simple and quick question. In freeipa or active directory,
>Is that all service principals don't change their symmetric key in the entire
>life time if no compromise occurred?
In Active Directory all service principals are aliases (service
principal names, SPNs) of the machine accounts of the machines on which
they are hosted. Machine account credentials are typically rotated at
some period, according to a domain-wide policy.

In FreeIPA we typically don't rotate the keys but there are tools that
allow such rotation to happen. Each principal has enough rights to
request its own key roation, so this is left for admins to decide
whether they would like to run something like the following:

kinit -k -t /path/to/keytab service-principal-name
ipa-getkeytab -k /path/to/keytab -p service-principal-name

periodically.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev