Re: crypto performance and RPCSEC_GSS

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Nicolas Williams (Nicolas.Williams@sun.com)
Date: 12/20/02-06:35:45 PM Z


Date: Fri, 20 Dec 2002 16:35:45 -0800
From: Nicolas Williams <Nicolas.Williams@sun.com>
Subject: Re: crypto performance and RPCSEC_GSS
Message-ID: <20021220163545.N1041@binky.central.sun.com>

Heh.  You're forgiven :)

But, you know, ideally we could specify a way to "upgrade" the security
of the stream underlying RPC, much as with HTTP and TLS, then downgrade
the RPCSEC_GSS security.  This would probably require some RPC
extension, perhaps it could be done as a new flavor, without having to
modify NFSv4 at all.

Cheers,

Nico

On Fri, Dec 20, 2002 at 04:31:40PM -0800, Mike Eisler wrote:
> There several (non-AUTH_SYS) alternatives to use for a lightweight
> identification only mechanism. I didn't intend to specify one at this time
> but promise to propose something even more elegant if there's
> consensus that the basic approach is what should be pursued.
> 
>  > AUTH_SYS at
>  > all for this purpose, no way, because the server is already
>  > mapping the
>  > GSS initiator principal names to its internal identifiers and we must
>  > preserve the server's ability to do so, whereas AUTH_SYS would take it
>  > away (and besides, the server would have to ensure that the AUTH_SYS
>  > data is valid for some established GSS context every time or
>  > use it as a
>  > GSS context lookup key - messy, messy).
> 
> Forgive me for my moment of weakness. Since implementors are already
> willing to add krb5 to their feature set, the lightweight scheme shouldn't
> be a big deal, as long as it is simple to code.
> 
>     -mre
> 
> 
> 


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:45 AM Z CST