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: 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

Re: FIPS certification

[Nicolas Williams]

On Fri, Feb 27, 2009 at 09:45:21PM -0800, Russ Allbery wrote:
> Randy Turner  writes:
> > 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?
> 
> I believe it would be extremely difficult (although maybe someone has made
> changes on this front and I've missed them).  If you want Kerberos
> libraries that use OpenSSL crypto, you'll probably find it easier to just
> use Heimdal, which already does so, than trying to change MIT Kerberos to
> do so.

Wyllys Ingersoll did it for Solaris a few years ago.  In Solaris the
Kerberos stack uses PKCS#11 (in user-land -- the kernel-land crypto
interfaces are different, but in the kernel Kerberos still uses the
Solaris crypto framework, instead of the MIT krb5 crypto code).

The biggest challenge _by far_ is krb5_keyblock.  The size of that
structure is part of the ABI because it was always in a public header
and code used (and still might) allocate krb5_keyblock variables as
automatics.  IIRC its layout too is part of the ABI.

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.

Sun would love for MIT to adopt changes to make MIT krb5 use PKCS#11.
Even using OpenSSL might work for us because we have the OpenSSL PKCS#11
ENGINE.

Nico
-- 

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

Re: FIPS certification

[Nicolas Williams]

On Fri, Feb 27, 2009 at 09:29:15PM -0800, Randy Turner wrote:
> 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?

MIT Kerberos has its own crypto code, yes.

Solaris Kerberos is based on MIT Kerberos and replaced the crypto with
calls to PKCS#11 (in user-land).  I believe the Solaris Kebreros team
wants to integrate these changes (challenging though it is) into MIT
krb5, but I don't know when it will happen.  That would be your best
bet.  The Solaris Kerberos stack is opensource, like most things in
OpenSolaris (though some parts under the CDDL, which MIT has in the past
considered incompatible with its aims, so Sun has donated code to MIT in
the past, meaning placed it under MIT's license).

If you're interested we can talk about the challenges in revamping MIT
krb5 to not use its own crypto code.

Nico
-- 

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

Re: FIPS certification

[Ken Raeburn]

On Feb 28, 2009, at 00:29, Randy Turner wrote:
> 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?

Not trivially.  There's no reason it couldn't be adapted to the  
OpenSSL crypto API (or the Apple CommonCrypto API, or anybody else's,  
providing they provide all the basic functions), and it's been  
discussed before, but the work hasn't been done yet.

> I'm assuming that MIT Kerberos has not been FIPS certified.

That's correct.

Ken


-- 
Ken Raeburn, Senior Programmer Analyst
MIT Kerberos Consortium http://www.kerberos.org/


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

Re: FIPS certification

[Russ Allbery]

Randy Turner  writes:

> 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?

I believe it would be extremely difficult (although maybe someone has made
changes on this front and I've missed them).  If you want Kerberos
libraries that use OpenSSL crypto, you'll probably find it easier to just
use Heimdal, which already does so, than trying to change MIT Kerberos to
do so.

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

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

FIPS certification

[Randy Turner]

Hello List,

I am working on a project that combines a number of different open- 
source libraries, all of which utilize some form of the same  
cryptographic operations, most notably symmetric ciphers, hashes, and  
public key cryptography.  The core of this project uses a FIPS- 
certified OpenSSL codebase.


The problem with combining open-source projects is that they seem to  
all come with their own implementation of crypto algorithms.


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?


I'm assuming that MIT Kerberos has not been FIPS certified.

Thanks!
Randy



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