Subject: RE: [nfsv4] more on gss authentication for callback

From: Mike Eisler <[email-masked]>
Date: Thu, 30 Oct 2003 14:42:51 -0800

> -----Original Message-----
 > From: Nicolas Williams [mailto:[email-masked]]
 > Sent: Thursday, October 30, 2003 2:16 PM
 > To: [email-masked]
 > Cc: [email-masked]
 > Subject: Re: [nfsv4] more on gss authentication for callback
 >
 >
 > On Thu, Oct 30, 2003 at 04:58:11PM -0500,
 > [email-masked] wrote:
 > > First, thanks a lot for the good info. I now have some idea
 > of what to do.
 > > One case I am curious about:
 > > - The client authenticates to the server for SetClientID with
 > > 	target: nfs@<serverhost.domain>
 > > 	initiator: root (or root@REALM in Kerberos jargon)
 >                    ^^^^
 > 		   root@<clienthost.domain>
 > > then, can the server authenticate the callback with
 > > 	target: root
 >                 ^^^^
 > 		root@<clienthost.domain>
 > > 	initiator: nfs@<serverhost.domain>	??
 >
 > The client has to have an acceptor credential[1] for
 > root@<clienthost.domain>.
 >
 > [1]  In Solaris SEAM, MIT krb5 and Heimdal parlance this
 > means having a
 >      keytab entry for root@<clienthost.domain>.

I can imagine a Kerberos V5 implementation that
caches the user's Kerberos password from kinit, and uses it
to produce the quasi-keytab entry for the purpose of user-to-user
Kerberos V5 authentication. It would not surprise me if
there is one today. But yes, today, for UNIX/Linux systems, it does
mean machine creds, and not user creds are the only ones that can be
used for SETCLIENTID over krb5.

 > Will it work?  For the Kerberos V GSS-API mechanis, yes.  For
 > LIPKEY, no.

Why not? Say the client and server each have access to a passwd database
kept in NIS or LDAP. Each NFS client and server has an entry in the database.
When the server makes a callback to the client, it supplies the server's
"user" name and password over the SPKM-3 protected session. This requires
each client to have an SPKM-3 private key and certificate. Which is why, the NFSv4
RFC3530 notes that since callbacks over LIPKEY require certificates on the client
and server, it is permissble for the server to issue the callback with pure SPKM-3,
and that the client SHOULD issue the SETCLIENTID with pure SPKM-3 (if wants callbacks).

So it works, but it is not sensible to do uses LIPKEY for callbacks.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 30 Oct 2003 15:01:43 -0800

> and that the client SHOULD issue the SETCLIENTID with pure SPKM-3 (if wants 

I did say LIPKEY, not SPKM-3.

As for SPKM-3, can this work without a client cert?  Would it be secure
without a client cert?  I think not.

> So it works, but it is not sensible to do uses LIPKEY for callbacks.

No, it's not sensible.

That's why we must purse the CCM-MIC approach.  And that means we need a
CB op for servers to ask clients to establish a GSS-API context in the
v4 channel for use with CCM-MIC in the CB channel.

Cheers,

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: 30 Oct 2003 18:25:37 -0500

>>>>> " " == Nicolas Williams <[email-masked]> writes:

     > That's why we must purse the CCM-MIC approach.  And that means
     > we need a CB op for servers to ask clients to establish a
     > GSS-API context in the v4 channel for use with CCM-MIC in the
     > CB channel.

Which is totally irrelevant for solving the problem on v4 since it is
not a mandated protocol...

CCM-MIC is 4.1. Let's deal with 4.0 *first*...

Cheers,
  Trond