Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal authentication

On Sep 4, 2014, at 11:33 AM, Nico Williams <nico@cryptonector.com> wrote:

> On Thu, Sep 4, 2014 at 6:57 AM, Adamson, Andy
> <William.Adamson@netapp.com> wrote:
>> 
>> On Sep 3, 2014, at 5:17 PM, Nico Williams <nico@cryptonector.com> wrote:
>> 
>>> On Wed, Sep 3, 2014 at 3:54 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
>>>> On Wed, 3 Sep 2014, J. Bruce Fields wrote:
>>>>> Sounds like there's work to do.
>>>> 
>>>> I agree.
>>> 
>>> I agree.  I wrote this eons ago and never got to implement.
>>> 
>>> Multi-principal authentication is critical for security on multi-user
>>> clients.  We should get it right.
>> 
>> Yes. But! If we add more structure to prevent aliasing - e.g. attach it to a client machine (or clientid) then it will
                              ^^^
should be “could” not necessarily “will"

>> prevent it’s use in NFSv4.2 Inter server to server copy where the user principal on one client machine is permitting another client (the destination server acting as a client) to act on it’s behalf.
> 
> Huh?   I don't see the connection.

Have you read the NFSv4.2 use of GSSv3 for inter server to server copy? The destination server (acting as an NFS client) needs to READ the file from the source server.  It needs to do so on behalf of the user-principal that starts the copy from the client. The destination server does not have a GSS context for the user-principal, as the user is logged onto the client, not the destination server.  The multi-principal nonce, MIC of nonce using the user-principal context is created on the client and sent with the user-principal context handle in a privacy protected structured privilege to the detination server which then uses it in a privacy protected multi-principal (plus structured privilege) assertion to the source server.

If the multi-principal nonce was replaced by data that tied the multi-principal use to a client machine, then in the above passing of the multi-principal data from the inter server to server client to the destination server (to allow the destination server to act on behalf of the user-principal) would not work.

In essence, NFSv4.2 inter server to server copy’s use of multi-principal assertion is aliasing.

> 
>> I say we keep the current nonce and simply insist on privacy. This will prevent aliasing and yet allow ti’s only current use case.
> 
> That's too risky.

Perhaps we allow a multi-principal aliasing mode.

—>Andy

> 
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten