Re: SSV is a cookie, not a key; why bother with HMAC?
Mike Eisler <email2mre-ietf <at> yahoo.com>
2007-04-10 16:57:28 GMT
--- Nicolas Williams <Nicolas.Williams <at> sun.com> wrote:
> On Tue, Apr 10, 2007 at 09:19:25AM -0700, Mike Eisler wrote:
> > --- Nicolas Williams <Nicolas.Williams <at> sun.com> wrote:
> > > I re-read section 188.8.131.52.
> > >
> > > I think it would be a lot simpler to say that:
> > >
> > > a) multi-user clients SHOULD (or even MUST) have their own
> > > and
> > > credentials for it and that they MUST do certain operations
> > > (creating
> > > sessions, binding connections to sessions, etc...) as that
> > > principal
> > > rather than as a user principal
> > What it says now:
> > If a client is assigned a machine principal then the client SHOULD
> > the machine principal's RPCSEC_GSS context to privacy protect the
> > from eavesdropping during the SET_SSV operation. If a machine
> > is not being used, then the client MAY use the non-machine
> > RPCSEC_GSS context to privacy protect the SSV. The server MUST
> > either type of principal. A client SHOULD change the SSV each time
> > new principal uses the session.
> You missed my point.
Or you are missing mine.
> What exactly is the purpose of SSV, and can it be replaced with
> something simpler?
To prevent Mallet from screwing up a session that Bob wants to
share with Alice.
As for simpler, .x file changes are closed, unless there is
a compelling reason.
> As near as I can tell the purpose of SSV is to decouple authorization
> addition of connections to a session from specific client principals
> (e.g., the one that created a session), instead relying on the client
> knowing some secret. The SSV does not provide comprehensive
> of a multi-user client using the Kerberos V mechanism against active
> attacks by its own users.
I don't know what you mean, so give an example.
> I don't think the SSV is necessary -- multi-user clients tend to,
> really, ought to have their own principals (those that don't can
> nonetheless cope).
The WG rough consensus is opposed to your opinion.
> > > If the WG really wants to support multi-user clients w/o their
> > > principal and credentials then we'll need to do something
> > > than
> > > what the I-D proposes or what I propose. Specifically we'll need
> > Why do we need to do something different?
> > Explain why what is there won't work.
> It's not that it won't work, it's that it's not needed.
I disagree. Your disagreement comes a little late, so the onus
is on you to make an argument why we should revisit session security
> > > way to do ephemeral key agreement (e.g., Diffie-Hellman) and bind
> > The SSV is a form of ephemeral key agreement.
> But it requires privacy protection, whereas ephemeral DH requires
> integrity protection. And going back to the previous point, the SSV
And apparently IPsec.
> does not provide comprehensive protection of a multi-user client from
> its users because where Kerberos V is used: a) the user can work out
> secret through eavesdropping, so the user can impersonate the client,
The user can only impersonate himself. So?
> this secret is not used to encrypt anything else, so the other users
> still actively attack the client.
> > Depending on IPsec is a nonstarter.
> What is the point of SSV? Is it to protect clients against their own
The point of the SSV:
- allow machine cred-less operation
- prevent attacks even when Kerberized NFS is being used
These were two problems with NFSv4.0, fixed with SSVs.
> users? If so, it's not comprehensive and you need to look at
> else, and I offer one solution; other solutions are possible. If
> is not the point of SSV, then why does it need to be so complicated,
> not just require that the same initiator that created a session be
> to bind new connections to it and call it a day?
Because that initiator may have logged off (e.g. done a kdestroy).
nfsv4 mailing list
nfsv4 <at> ietf.org