Re: Public key AuthMethod

[biran@il.ibm.com]

Spencer,

Thanks for pointing out this info. I had another correspondence
with the CAT-WG chair, and first, the erroneous Experimental-labeled
version has now been replaced on the IETF web site.

For the advancing question, in regard to RFC-2847 he said:

"The question of whether/when RFC-2025 will advance to Draft is a
separate and more complex one, and isn't equivalent to the question of
advancing RFC-2847 (which is a derived specification, based on a subset of
RFC-2025).  Either/both would be IESG decisions, based in part on the
status
of interoperable implementations"

In view of all this, I will go ahead and define the
public key AuthMehtod based on RFC-2025 (mainly because
this is the only standard we have for this) - unless
I hear strong opposition / better suggestion.

  Regards,
    Ofer


Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com  972-4-8296253


Spencer Shepler <shepler@eng.sun.com> on 04/03/2001 09:07:20 PM

Please respond to shepler@eng.sun.com

To:   Ofer Biran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu, mike@eisler.com
Subject:  Re: Public key AuthMethod





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 -