Re: Is a keytab file encrypted?

[Charles Hedrick]

You can only use the host key table from a host with the same IP address. The 
server verifies that the IP address corresponds to the hostname. In theory 
someone could bring a laptop and plug it in in place of the original host with 
the same IP address, but that wouldn’t let them compromise anything they 
couldn’t already get if they had root on the original host. We do lots of 
monitoring. If one of our hosts disappears, we’ll notice. If they replace it 
with another host at the same IP address that’s close enough to the original 
that we don’t  notice, it’s not clear what is being compromised. They’re just 
giving us free hardware...

And at least in our situation, we have various groups of systems at different 
security levels. So you could compromise that user on one cluster, but not 
system-wide. 


> On Jul 21, 2017, at 5:55:27 PM, Russ Allbery  wrote:
> 
> Russ Allbery  writes:
>> Charles Hedrick  writes:
> 
>>> * A kerberized service where the user registers that they want to be
>>> able to do cron jobs on a given machine.
>>> * A kerberized pam module that calls the same service and gets back
>>> credentials, locked to the IP address, and at least by default not
>>> forwardable.
> 
>> How does this address the problem raised on this thread?  It's still the
>> case that if you become root on the host, you can just steal the keytab
>> used by that daemon and use it anywhere.  This gives you enhanced
>> protection if you trust the boundary between non-root users and root,
>> but not if you don't trust the machine.
> 
> Oh, wait, I see -- it does transform part of the attack to occasional
> on-line, since while you can steal the system keytab and request tickets
> whenever you want, you can't get the long-lived keytab for the actual
> target credential.  (And presumably you can put monitoring and alerting
> around the host keytab being used from unexpected places.)
> 
> Yeah, that's a partial security improvement.
> 
> -- 
> Russ Allbery (ea...@eyrie.org)  
> 



Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: client IP address in Kerberos ticket.

[Russ Allbery]

Jim Shi  writes:

> Hi, I have question regarding client IP address checking in KDC.  Is
> that true that by default  tickets  issued by KDC is not bound to any
> client IP address.  Also KDC server does not check IP if the ticket does
> not have  any client IP address in it.

> Do we have to explicitly  turn on the client IP address checking on KDC?
> How to do it?  Thank you very much.

I am dubious that IP address checking is a meaningful security measure.
My recommendation would be to forget that it exists and not rely on it for
your security model.

You're correct that the default value of the noaddresses configuration
option is true, largely because address-locked tickets tend to cause tons
of problems in modern network environments that often involve NAT.

-- 
Russ Allbery (ea...@eyrie.org)  


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Is a keytab file encrypted?

[Russ Allbery]

Russ Allbery  writes:
> Charles Hedrick  writes:

>> * A kerberized service where the user registers that they want to be
>> able to do cron jobs on a given machine.
>> * A kerberized pam module that calls the same service and gets back
>> credentials, locked to the IP address, and at least by default not
>> forwardable.

> How does this address the problem raised on this thread?  It's still the
> case that if you become root on the host, you can just steal the keytab
> used by that daemon and use it anywhere.  This gives you enhanced
> protection if you trust the boundary between non-root users and root,
> but not if you don't trust the machine.

Oh, wait, I see -- it does transform part of the attack to occasional
on-line, since while you can steal the system keytab and request tickets
whenever you want, you can't get the long-lived keytab for the actual
target credential.  (And presumably you can put monitoring and alerting
around the host keytab being used from unexpected places.)

Yeah, that's a partial security improvement.

-- 
Russ Allbery (ea...@eyrie.org)  

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Is a keytab file encrypted?

[Russ Allbery]

Charles Hedrick  writes:

> * A kerberized service where the user registers that they want to be
> able to do cron jobs on a given machine.
> * A kerberized pam module that calls the same service and gets back
> credentials, locked to the IP address, and at least by default not
> forwardable.

How does this address the problem raised on this thread?  It's still the
case that if you become root on the host, you can just steal the keytab
used by that daemon and use it anywhere.  This gives you enhanced
protection if you trust the boundary between non-root users and root, but
not if you don't trust the machine.

The point of the TPM is that you can't exfiltrate the keys, even if you
have root, only perform on-line operations.

-- 
Russ Allbery (ea...@eyrie.org)  

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

client IP address in Kerberos ticket.

[Jim Shi]

Hi, I have question regarding client IP address checking in KDC.
Is that true that by default  tickets  issued by KDC is not bound to any client 
IP address.
Also KDC server does not check IP if the ticket does not have  any client IP 
address in it.

Do we have to explicitly  turn on the client IP address checking on KDC? How to 
do it?
Thank you very much.

Jim

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Is a keytab file encrypted?

[Charles Hedrick]

My approach is simpler:

* A kerberized service where the user registers that they want to be able to do 
cron jobs on a given machine. 
* A kerberized pam module that calls the same service and gets back 
credentials, locked to the IP address, and at least by default not forwardable.

The pam module authenticates using the system keytable.

This may not be quite as good as a TPM, because it depends upon the integrity 
of the system key table. But the service checks the IP address, so my host 
credential is host/FOO, a lookup of FOO has to produce the IP address the 
request came from. That seems pretty close. I’ll look into TPM, to see if that 
could somehow be used.

> On Jul 21, 2017, at 3:42 PM, Russ Allbery  wrote:
> 
> Charles Hedrick  writes:
> 
>> The argument makes sense.
> 
>> However I am disturbed by the fact that a keytab can be used
>> anywhere. If someone manages to become root on one machine, I’d like
>> them not to be able to do things on other machines. I’m in an
>> environment where we have systems administered by users, and unattended
>> public workstations.
> 
>> That makes me unwilling to tell users to create key tables for cron
>> jobs.
> 
> Yeah, if you're worried about portable keys, that's when you probably want
> to do something with a system TPM.  If you go down that path, I'd probably
> try to figure out some way to do PKINIT using a TLS certificate stored in
> the TPM.  I'm not aware of anyone who has already done that work, but it
> would be a pretty interesting project.
> 
> -- 
> Russ Allbery (ea...@eyrie.org)  
> 



Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Is a keytab file encrypted?

[Russ Allbery]

Charles Hedrick  writes:

> The argument makes sense.

> However I am disturbed by the fact that a keytab can be used
> anywhere. If someone manages to become root on one machine, I’d like
> them not to be able to do things on other machines. I’m in an
> environment where we have systems administered by users, and unattended
> public workstations.

> That makes me unwilling to tell users to create key tables for cron
> jobs.

Yeah, if you're worried about portable keys, that's when you probably want
to do something with a system TPM.  If you go down that path, I'd probably
try to figure out some way to do PKINIT using a TLS certificate stored in
the TPM.  I'm not aware of anyone who has already done that work, but it
would be a pretty interesting project.

-- 
Russ Allbery (ea...@eyrie.org)  


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Is a keytab file encrypted?

[Jeffrey Altman]

On 7/21/2017 11:13 AM, Charles Hedrick wrote:
> The argument makes sense.
> 
> However I am disturbed by the fact that a keytab can be used anywhere. If 
> someone manages to become root on one machine, I’d like them not to be able 
> to do things on other machines. I’m in an environment where we have systems 
> administered by users, and unattended public workstations.
> 
> That makes me unwilling to tell users to create key tables for cron jobs.

Sites have implemented a wide variety of approaches to authenticating
cron jobs.  The cron process is specific to a host and is not the user.
As such some sites provide tooling that issues host specific principals
for such use with cron:

  user/cron/hostname@REALM

is a common format.  It is then up to the service receiving such a
principal to ensure that the authenticating client is in fact connecting
from the specified host.  Authorization rules can be applied as desired
to either grant specific permissions to

  user/cron/hostname@REALM
  user/cron/*@REALM
  user/*/*@REALM

with appropriate name folding.

Jeffrey Altman





smime.p7s
Description: S/MIME Cryptographic Signature

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Is a keytab file encrypted?

[Charles Hedrick]

The argument makes sense.

However I am disturbed by the fact that a keytab can be used anywhere. If 
someone manages to become root on one machine, I’d like them not to be able to 
do things on other machines. I’m in an environment where we have systems 
administered by users, and unattended public workstations.

That makes me unwilling to tell users to create key tables for cron jobs.


> On Jul 18, 2017, at 10:20 PM, pratyush parimal  
> wrote:
> 
> Ah, I get it. It's much clearer now. Thanks guys!
> 
> On Jul 18, 2017 10:15 PM, "Russ Allbery"  wrote:
> 
>> Greg Hudson  writes:
>>> On 07/18/2017 12:48 PM, pratyush parimal wrote:
>> 
 (2) Is it possible to export the key in encrypted form? If so, then how
 does the service application open the encrypted keytab?
>> 
>>> The keytab file does not have any way to represent encrypted keys, and
>>> the kadmin protocol has no facility to export encrypted keys.  One
>>> could, in principle, design an out-of-band system which used
>>> kadmin.local to create a keytab, encrypt the file, transmit the
>>> encrypted kyetab file to the server, and then decrypt the file on the
>>> server (into a memory filesystem, perhaps) before running the server
>>> application, but I've never heard of anyone doing that.
>> 
>> You have kind of a chicken and an egg problem, since in a typical Kerberos
>> environment the keytab *is* the core identity keys for an application.  If
>> it's encrypted, then you need some other unencrypted keys that *really*
>> represent the application, at which point why not use those keys for
>> Kerberos directly?
>> 
>> That said, if you had a private key in a TPM or some other sort of
>> tamper-resistent hardware, I could see wanting to hand out Kerberos
>> keytabs encrypted to the public key of the server.  But you'd have to
>> build the service to do key issuance that way yourself.  (It wouldn't be
>> horribly hard to build if you'd already done the work to build out the PKI
>> and its TPM component.)
>> 
>> But, even in that case, it's not clear to me what the keytab is then doing
>> for you versus just using the PKI and using PKINIT to get Kerberos
>> tickets.  There are probably some practical uses for introducing the extra
>> layer of complexity, but it's not obviously necessary.
>> 
>> --
>> Russ Allbery (ea...@eyrie.org)  
>> 
>> 
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.mit.edu%2Fmailman%2Flistinfo%2Fkerberos&data=02%7C01%7Chedrick%40rutgers.edu%7Cd8fbc3140d2741aa9bce08d4ce4d0583%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636360277603180808&sdata=GaOrAUT3ukJJgW3X8l9nbRJHGkBah2K9VIeLXdiLpJo%3D&reserved=0



Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos