Re: FIPS certification

[Luke Howard]

> I haven't completely analyzed MIT Kerberos, but I was wondering if  
> it would be possible to get the MIT Kerberos subsystem to use the  
> OpenSSL crypto API for any cryptographic support needed for Kerberos?

Novell did this, but I'm not sure if they ever released their changes,  
or if it was done in such a way that it would be acceptable by MIT.

-- Luke

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

Re: Long-running jobs with renewal of krb5 tickets and AFS tokens

[Russ Allbery]

Jason Edgecombe  writes:

> I guess setting things for renewable tickets longer than 7 days or
> running the jobs in local disk will be easiest.
>
> We have a 7 day normal/renewable lifetime. What length do other sites
> have?

Seven days here as well.  That's also our limit on how long we let compute
jobs run on our normal timeshare systems.  We're working on a batch
queuing system that will use separate cron instances.

> I might need use the job scheduler approach, but that's a pain. I would
> guess 10-20 people would want that ability. I ether need to modify our
> account maintenance processes or do it all manually.
>
> Has anyone automated the management of user.cron principals?
> unfortunately, I have had to tell people that they can't have an
> infinite ticket lifetime. :P

We've automated similar things here and there's some support for it in the
kadmin-remctl package.  I'm hoping to clean that up substantially at some
point, but haven't had the time (and it's not in the top hundred on my
priority list at the moment).

-- 
Russ Allbery (r...@stanford.edu) 

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

Re: Long-running jobs with renewal of krb5 tickets and AFS tokens

[Jason Edgecombe]

Russ Allbery wrote:
> Jason Edgecombe  writes:
>
>   
>> We have users who need to run long-running jobs and store their files in
>> AFS during the run.
>>
>> I've read the k5start and k5renew man pages, but I don't see how I can
>> have users type in their password when they start a job and have the
>> tickets and tokens keep being renewed.
>>
>> How can I do this?
>> 
>
> If you're not dealing with a batch environment, where the execution
> happens some time after the user authenticates, then krenew is what you
> want.  It just doesn't do the initial ticket acquisition.
>
> You configure your PAM module and krb5.conf to get renewable tickets by
> default, so that the user already has renewable tickets when they start
> the job.  Then run the job under krenew.  It will make a private copy of
> the existing ticket cache and then keep renewing tickets and tokens until
> either it can't any more or the job ends.
>
> If you *are* dealing with a batch environment, you want Kula's approach.
>   
Sigh,

I guess setting things for renewable tickets longer than 7 days or 
running the jobs in local disk will be easiest.

We have a 7 day normal/renewable lifetime. What length do other sites have?

I might need use the job scheduler approach, but that's a pain. I would 
guess 10-20 people would want that ability. I ether need to modify our 
account maintenance processes or do it all manually.

Has anyone automated the management of user.cron principals? 
unfortunately, I have had to tell people that they can't have an 
infinite ticket lifetime. :P

Thanks for the help!

Thanks,
Jason

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

Re: Long-running jobs with renewal of krb5 tickets and AFS tokens

[Russ Allbery]

Thomas Kula  writes:

> I don't think k5start has an option that prompts you for a password
> *and* remembers it to keep renewing credentials on your behalf, but
> since I always just use the keytab option I'm not as familiar with that
> use of k5start.

k5start intentionally doesn't support this because I think it undermines
the Kerberos security model.

-- 
Russ Allbery (r...@stanford.edu) 

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

Re: Long-running jobs with renewal of krb5 tickets and AFS tokens

[Russ Allbery]

Jason Edgecombe  writes:

> We have users who need to run long-running jobs and store their files in
> AFS during the run.
>
> I've read the k5start and k5renew man pages, but I don't see how I can
> have users type in their password when they start a job and have the
> tickets and tokens keep being renewed.
>
> How can I do this?

If you're not dealing with a batch environment, where the execution
happens some time after the user authenticates, then krenew is what you
want.  It just doesn't do the initial ticket acquisition.

You configure your PAM module and krb5.conf to get renewable tickets by
default, so that the user already has renewable tickets when they start
the job.  Then run the job under krenew.  It will make a private copy of
the existing ticket cache and then keep renewing tickets and tokens until
either it can't any more or the job ends.

If you *are* dealing with a batch environment, you want Kula's approach.

-- 
Russ Allbery (r...@stanford.edu) 

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

Re: Long-running jobs with renewal of krb5 tickets and AFS tokens

[Thomas Kula]

On Sat, Feb 28, 2009 at 05:42:58PM -0500, Jason Edgecombe wrote:
> We have users who need to run long-running jobs and store their files in 
> AFS during the run.
> 
> I've read the k5start and k5renew man pages, but I don't see how I can 
> have users type in their password when they start a job and have the 
> tickets and tokens keep being renewed.
> 
> How can I do this?

Give them a keytab, but not one for their normal identity (this
breaks things). Create, rather, an instance for them that can
be put in a keytab, give that instance permission to do whatever
it needs to do in AFS, and use the option to k5start that has it
use a keytab instead of asking for a password.

For example, here's what I do for cronjobs that need to access
AFS:

 - create a principal user/cron (e.g. kula/cron)
 - extract that into a keytab
 - put the keytab somewhere on local disk where only the
   user can get to it
 - Do what you need to do to give user/cron access to 
   files in AFS (create the PTS identity user.cron, put
   that on the appropriate ACLs)
 - Teach the user how to give the proper incantation to 
   k5start to get credentials from they keytab and keep
   renewing them until the job finishes.

This presumes, of course, that it works in your setup to put
that keytab somewhere on local disk and that the user will 
start the job from a machine that has the keytab on local
disk. Also, remember off course, that access to the keytab
gives access to the files, so protect it accordingly.

I've also had good luck starting a screen session inside of
it's own pag and with it's own credentials cache, and in one
window have something that runs the job and in another window
something renewing the user's credentials. That could be
something as simple as "user must remember to attach the screen
session every N hours and renew their credentails" to using
k5start with the keytab idea above. I don't think k5start has
an option that prompts you for a password *and* remembers it
to keep renewing credentials on your behalf, but since I always
just use the keytab option I'm not as familiar with that use
of k5start. If there is such an option, remember to treat the
environment it runs in as securely as you would treat the user's
credentials cache, since, well, that process has the user's 
password.

There are probably several other ways of doing this, but these
are a couple that have worked well for me, and at work we've
helped a couple users do the screen option, so at least someone
other than me can understand the process well enough to use
it (your users, of course, may vary).


-- 
Thomas L. Kula | k...@tproa.net | http://kula.tproa.net/

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

Long-running jobs with renewal of krb5 tickets and AFS tokens

[Jason Edgecombe]

We have users who need to run long-running jobs and store their files in 
AFS during the run.

I've read the k5start and k5renew man pages, but I don't see how I can 
have users type in their password when they start a job and have the 
tickets and tokens keep being renewed.

How can I do this?

Thanks,
Jason

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

Re: FIPS certification

[Nicolas Williams]

On Sat, Feb 28, 2009 at 01:56:22PM -0600, Nicolas Williams wrote:
> On Sat, Feb 28, 2009 at 01:07:50PM -0500, Ken Raeburn wrote:
> > We'd also still need to handle the krb5_keyblock structure embedded in  
> > krb5_creds; in that instance it wouldn't be extensible.
> 
> I suspect we can handle that by having a new krb5_keyblock for all
> non-krb5_creds uses of it, and krb5_keyblock_old for krb5_creds.  It's
> only the auth_context and the GSS mech where we need to be able to cache
> derived keys and what not (crypto library handles).

There is another way...

If we only care about performance in the GSS mechanism then there's no
need to change krb5_keyblock.  That means crypto in the raw krb5 API
apps will not be as good, mostly because of the lack of derived key
caching and because of the lack of caching of crypto library handles
(including key schedules).  But MIT krb5 already suffers from this
anyways.

Nico
-- 

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

Re: FIPS certification

[Theodore Tso]

On Sat, Feb 28, 2009 at 01:07:50PM -0500, Ken Raeburn wrote:
> We'd also still need to handle the krb5_keyblock structure embedded in  
> krb5_creds; in that instance it wouldn't be extensible.
> 
> It'd be so nice to be able to do a new API for a v2.0 someday. :-)

But then I wouldn't be able to use Krb5 as the poster child for badly
designed legacy API's that make ABI compatibility really hard any
more.  

(My excuse, since a large amount of it was my fault, was that I was
young and folish  :-)

Seriously, that might not be a bad idea, one of these days

   - Ted

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

Re: FIPS certification

[Nicolas Williams]

On Sat, Feb 28, 2009 at 01:07:50PM -0500, Ken Raeburn wrote:
> We'd also still need to handle the krb5_keyblock structure embedded in  
> krb5_creds; in that instance it wouldn't be extensible.

I suspect we can handle that by having a new krb5_keyblock for all
non-krb5_creds uses of it, and krb5_keyblock_old for krb5_creds.  It's
only the auth_context and the GSS mech where we need to be able to cache
derived keys and what not (crypto library handles).

Nico
-- 

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

Re: FIPS certification

[Nicolas Williams]

On Sat, Feb 28, 2009 at 01:07:50PM -0500, Ken Raeburn wrote:
> On Feb 28, 2009, at 12:43, Theodore Tso wrote:
> > It might be possible to dispatch on krb5_keyblock->magic to determine
> > whether it the new fields are there, and in places where a passed in
> > krb5_keyblock is allocated on the stack, the called function could
> > allocate a new-style krb5_keyblock and import the key.  (How many such
> > places are there?  I didn't think there would be that many.)  It
> > wouldn't be that pretty, yes, but if it's considered important to
> > preserve the ABI, it's probably doable...
> 
> Yeah, that's been considered.  It's a little risky in that sometimes  
> the "magic" field just isn't initialized (especially in an application- 
> provided keyblock), and adding a dependence on it (at least on it  

Actually, is it ever initialized when allocated on the stack?  I suspect
not.

It's been pointed out to me that it's not necessary to change
krb5_keyblock just to use OpenSSL, and I think one could argue the same
for PKCS#11.  However, leaving krb5_keyblock unchanged is sub-optimal,
and, most importantly for performance, means you can't cache derived
keys in the keyblock itself (you could have a hash table).

> *not* having a certain 32-bit value that indicates the extended form)  
> would be a minor ABI change.  I think the risk is probably low, and  
> it'd probably be worth the extra ugliness to get the benefits.
> 
> We'd also still need to handle the krb5_keyblock structure embedded in  
> krb5_creds; in that instance it wouldn't be extensible.
> 
> It'd be so nice to be able to do a new API for a v2.0 someday. :-)

Yes.

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

Re: FIPS certification

[Ken Raeburn]

On Feb 28, 2009, at 12:43, Theodore Tso wrote:
> It might be possible to dispatch on krb5_keyblock->magic to determine
> whether it the new fields are there, and in places where a passed in
> krb5_keyblock is allocated on the stack, the called function could
> allocate a new-style krb5_keyblock and import the key.  (How many such
> places are there?  I didn't think there would be that many.)  It
> wouldn't be that pretty, yes, but if it's considered important to
> preserve the ABI, it's probably doable...

Yeah, that's been considered.  It's a little risky in that sometimes  
the "magic" field just isn't initialized (especially in an application- 
provided keyblock), and adding a dependence on it (at least on it  
*not* having a certain 32-bit value that indicates the extended form)  
would be a minor ABI change.  I think the risk is probably low, and  
it'd probably be worth the extra ugliness to get the benefits.

We'd also still need to handle the krb5_keyblock structure embedded in  
krb5_creds; in that instance it wouldn't be extensible.

It'd be so nice to be able to do a new API for a v2.0 someday. :-)

Ken

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

Re: FIPS certification

[Theodore Tso]

On Sat, Feb 28, 2009 at 12:01:46AM -0600, Nicolas Williams wrote:
> 
> Solaris at the time did not expose a krb5 API, so it was trivial for us
> (Wyllys) to change krb5_keyblock and to add initializers for it.  But
> when it comes to contributing these changes to MIT we'll run into this
> problem.  There are solutions that preserve compatibility with code that
> allocates krb5_keyblock on the stack, but they aren't pretty.  Breaking
> the ABI could be considered -- it'd be a smallish break, but it won't be
> Sun deciding that, but the MIT Kerberos community.

It might be possible to dispatch on krb5_keyblock->magic to determine
whether it the new fields are there, and in places where a passed in
krb5_keyblock is allocated on the stack, the called function could
allocate a new-style krb5_keyblock and import the key.  (How many such
places are there?  I didn't think there would be that many.)  It
wouldn't be that pretty, yes, but if it's considered important to
preserve the ABI, it's probably doable...

- Ted

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