Re: Public key AuthMethod

[Spencer Shepler <shepler@eng.sun.com>]

Note that NFSv4 specifies LIPKEY (RFC2847) and SPKM-3 as mandatory to
implement.  LIPKEY/RFC2847 builds upon the SPKM RFC and defines the
SPKM-3 mechanism which meets the needs of NFSv4.  SPKM-3/LIPKEY is
being implemented and therefore the SPKM RFC may be moving forward as
part of the NFSv4 work.

Spencer

On Tue, biran@il.ibm.com wrote:
> 
> 
> In Minneapolis I proposed to add the public key AuthMethod based on
> SPKM (public key implementation of GSS-API, RFC-2025). SPKM is really
> suitable (it gives the exact definition of tokens to be exchange in iSCSI
> text
> messages for public key authentication including optional certificates
> exchange, and MAC digest based on shared key generated by the
> exchange, that might be negotiated in the iSCSI login).
> 
> However, there is a question mark about the status of RFC-2025. It is on
> standards truck at Proposed Standard level, but it is from 1996... I had
> a correspondence with the CAT-WG chair, and here are two citations:
> 
> "I'm unaware, however, of any current plans for advancement of this
> document
> beyond Proposed and it hasn't been actively discussed within the WG for
> some
> time. I'm also unsure as to its number of existing implementations."
> 
> "Nonetheless, I believe that it remains well suited as a specification for
> an
> X.509-based authentication mechanism.  I'm not aware of an alternative
> specification with comparable scope currently defined within an Internet
> standards-track RFC"
> 
> (BTW, if you look at the version linked from the RFC pages, the
> "Status of this Memo" section states:
> "This memo defines an Experimental Protocol for the Internet community..."
> however the same section in the version fetched from the RFC Editor-pages
> states:
> "This document specifies an Internet standards track protocol for the
>    Internet community..."
> the CAT-WG chair confirmed that the first copy is a mistake.)
> 
> In anyway, can we (/ should we) rely on RFC that its plan for becoming a
> standard is not clear at all?
> 
> Another option for the public key AuthMethod might be a reduced version
> of the TLS handshake (implemented in the iSCSI text messages, not using
> the TLS record layer).  This can provide authentication (with optional
> certificate exchange) and a shared secret that can be used for MAC
> digest according to the TLS MAC specification (but used of course as
> optional iSCSI digest and not inside TLS).
> 
> I believe it's preferable to adopt an existing security standard as much
> as possible than inventing something new for iSCSI.
> 
> I'd like to hear some opinions on these before we decide how to define
> the public key AuthMethod.
> 
> Regards,
>   Ofer
> 
> 
> Ofer Biran
> Storage and Systems Technology
> IBM Research Lab in Haifa
> biran@il.ibm.com  972-4-8296253
> 
> 

-- 

- Spencer -