[16083] in Kerberos_V5_Development
Re: Info regarding MIT 1.8 Crypto modularity feature.
daemon@ATHENA.MIT.EDU (Henry B. Hotz)
Thu Aug 19 12:28:28 2010
Mime-Version: 1.0 (Apple Message framework v1081)
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
In-Reply-To: <AANLkTimiG=7964wt3rCM7MYcDFbScKWdf8MTO8Y34aYn@mail.gmail.com>
Date: Thu, 19 Aug 2010 09:28:20 -0700
Message-Id: <250CC79A-19C0-4D7B-9A73-6A28796FFB02@jpl.nasa.gov>
To: Use Nas <usenas@gmail.com>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Theoretically it can't, and it really shouldn't cause any interop issues because the wire protocol is specified and (to some real extent) independently tested. The real world has a way of not living up to those ideals perfectly of course, but I'd worry more about cross-implementation issues: MIT<-->Heimdal, MIT<-->Microsoft, etc.
On Aug 18, 2010, at 10:55 PM, Use Nas wrote:
> I have another questions regarding crpto modularity implementation for openssl. Will it break anything if the client and server are at different levels. ( Server with latest MIT 1.8. & client with MIT 1.5 ) ? What needs to be taken care of in these cases?.. And i believe openssl is supporting only limited encrytion alogos .. The rest are in krb folder? Please help me understand it
>
> Thanks in advance.
>
> On Tue, Aug 17, 2010 at 12:02 PM, Use Nas <usenas@gmail.com> wrote:
> I would like to have a framework on top of crypto implementation, which virtualizes these implementations [ using virtual crypto interfaces ] and based on the user input [ configurable option ], switch to specific type of crypto implementation.
>
> Thanks
>
>
>
> On Tue, Aug 17, 2010 at 6:54 AM, Henry B. Hotz <hotz@jpl.nasa.gov> wrote:
>
> On Aug 16, 2010, at 9:05 AM, krbdev-request@mit.edu wrote:
>
> > Date: Mon, 16 Aug 2010 11:31:51 -0400
> > From: Zhanna Tsitkova <tsitkova@MIT.EDU>
> > Subject: Re: Info regarding MIT 1.8 Crypto modularity feature.
> > To: "jaltman@secure-endpoints.com" <jaltman@secure-endpoints.com>
> > Cc: "krbdev@mit.edu" <krbdev@mit.edu>
> > Message-ID: <74E2309B-04BF-4712-A59B-FE445293214B@mit.edu>
> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
> >
> > Well, we have discussed these scenarios internally and ended up with
> > "one crypto implementation per kerberos crypto library" scenario for
> > the reasons of better sense of security and integrity.
> > For example, mixing FIPS 140.2 and non-FIPS modes - who wants to be
> > FIPS approved? - finance, government, heathcare and friends. It is
> > unlikely that any of them would consider refining and potentially
> > jeopardizing their configuration to speed-up things for the sake of
> > slight (or even significant) performance gain. Or, at least, they
> > would definitely use different machines for these different tasks.
> > As for Shipping a binary that can support hardware and non-hardware
> > implemented encryption, this case is tougher one to ague with.
> > However, I think, if hardware accelerators are available, one will
> > always prefer to take advantage of them.
> > Finally, performance testing, in my opinion, is much cleaner when it
> > does not resolve the specifics of the configuration setup during run-
> > time.
>
> I think these are all arguments that it's possible to live without run-time library selection, rather than arguments that users necessarily prefer being locked into a single selection.
>
> Ignoring implementation difficulty (which is a big deal, I know) I would always prefer to have the run-time option as long as the option never causes any run-time failures. ;-)
>
> FIPS-mode seems like a special case. A FIPS-approved library (well, at least openssl) is likely to have a non-FIPS mode which may be faster and probably supports additional encryption types (RC4, Camillia?). I'd think it was trivial to select FIPS/non-FIPS at run time, and that might make it easier to flag non-FIPS to a user who is expecting FIPS mode.
> ------------------------------------------------------
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
>
>
>
>
> _______________________________________________
> krbdev mailing list krbdev@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
