|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Public key AuthMethodNote 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 -
Home Last updated: Tue Sep 04 01:05:11 2001 6315 messages in chronological order |