Re: [SPKM] Re: [67th IETF] SPKM3 BOF announcement

[Nicolas Williams <[e-mail]>]

On Thu, Oct 12, 2006 at 06:36:07PM -0400, Razvan Trufasiu wrote:
> My name is Razvan Trufasiu, and I am in charge of developing an
> SPKM-3/LIPKey implementation for the Hummingbird NFS Maestro server.

Excellent.  Nice to meet you.

> At the moment, Hummingbird NFSv4 implementation supports anonymous SPKM-3
> and LIPKey, and the next version will hopefully implement mutual SPKM-3. Any
> of these are based upon the specs released in early 2006. The specs have
> already changed, from my understanding; however, updating the code to
> support this should be simple. For interoperability, currently Olga and I
> managed to run several Connectathon tests successfully, without Integrity or
> Privacy. We can connect (tentatively) with Integrity, and are working on
> being able to connect with Privacy, and run all the tests. There are several
> problems we are currently still addressing.

You may want to adapt Microsoft's GSS-MONGER test suite.  The
Connectathon tests test NFS use of GSS-API mechanisms, but lack a
thourough test of GSS mechanisms vis-a-vis the GSS-APIv2u1.  I believe
Martin Rex has a test suite that you might be able to get access too.

> The reason we have chosen to implement SPKM-3 or LIPKey is to provide an
> alternative GSS implementation to Kerberos v5.

I'm with you.

>                                                Kerberos is often difficult
> to set up, and the overhead of having a separate Kerberos server, in
> addition to the NFS client/server can be cumbersome for certain users.

I don't think this is the reason for wanting other mechanisms.  But it
doesn't matter -- I agree that mechanisms based on credential types
other than Kerberos V tickets are desirable.

> LIPKey and anonymous SPKM-3 are easy to set up and quick to deploy, even on
> large networks, without compromising the main security of GSS (although the
> anonymous part of either protocol does come with some problems, such as
> anonymous SPKM not doing any sort of client-side security checks). It would
> also be a huge asset if the implementation of this protocol turns out to be
> faster and more performing than Kerberos v5 (which it is not at the moment).

There is the matter of distributing trust anchors, CRLs/OCSP, etc...

I don't think mechanism performance is an issue here.  SPKM performance
should be roughly comparable to TLS, SSHv2, etc...  Given its use of
public key cryptographic it certainly could not be much faster than
existing secure protocols that also use public key cryptographic.  Given
use of PKIX then there's the whole CRL/OCSP ball of wax too, that can
impact performance.

Yes, some Kerberos V implementations suffer from, for example, poorly
performing replay caches, which SPKM-3 should not need, so there's
always a possibility that some SPKM-3 implementations could be faster
than certain Kerberos V mechanism implementations.

Bottom-line: SPKM isn't needed for performance reasons.

Nico
-- 

_______________________________________________
SPKM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/spkm