Subject: [nfsv4] SSV is a cookie, not a key; why bother with HMAC?

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Apr 2007 11:47:24 -0500

I just realized that NFSv4.1 is doing some crypto things beyond what
RPCSEC_GSS provides.

My reading of the I-D is that there's a cookie-like thing the I-D calls
an "SSV" (shared secret value) and, sometimes a "key" and which is
computed by using HMAC in a challenge/response type mechanism
construction, but using public values -- i.e., there's no real key
agreement, and no pre-shared keys.  The whole thing depends on
RPCSEC_GSS privacy protection.

Did I get this right?

If so, I've some observations:

 o This SSV thing is not what I would call a key, and the scheme for
   setting it up is not what I would call a key exchange.  The SSV is
   really much more like a cookie than like a key.

   Calling this a cookie will be less confusing to folks who weren't
   involved in the 4.1 design.

 o No crypto [beyond what RPCSEC_GSS provides] is actually needed in
   order to exchange cookies.  Just pick a large cookie randomly and
   you're done; 64-bits should suffice.

   Not using a cryptographic protocol to generate this cookie will help
   keep implementations simple.

Also, are SSVs required?  If so then that would mean that 4.1 would also
REQUIRE support for RPCSEC_GSS privacy protection, no?

Nico
-- 

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

---

From: Mike Eisler <[email-masked]>
Date: Fri, 6 Apr 2007 10:01:12 -0700 (PDT)

> computed by using HMAC in a challenge/response type mechanism

No the SSV is used as input into HMAC. HMACs require shared
secret keys between the entity computing the digest and the
entity verifying the digest.

> RPCSEC_GSS privacy protection.

It does depend on RPCSEC_GSS privacy in order to prevent 
denial of service. The DoS attacks are described in detail in
the spec, and were discussed in detail on the mailing list.
> Did I get this right?

I think you've got lots of stuff wrong. Curious, since when
I laid this all out on the mailing list before adding it the spec,
you blessed it.

>    really much more like a cookie than like a key.

HMACs take keys. SSV is the input to HMAC. QED.

>    you're done; 64-bits should suffice.

I disagree. Read the spec to understand the DoS. There may be
other solutions, but there has to be a very compelling reason to
change the spec to use a different solution.

>    keep implementations simple.

Actually XOR is used to generate the cookie (as a new user uses the
session, the client issues SET_SSV [with RPCSEC_GSS
privacy] to update the SSV).
> REQUIRE support for RPCSEC_GSS privacy protection, no?

MUST for servers, SHOULD for clients, therefore, servers MUST support
privacy, at least for SET_SSV.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Apr 2007 13:22:30 -0500

> the spec, and were discussed in detail on the mailing list.

I'll read it again more closely.

> I laid this all out on the mailing list before adding it the spec,

I blessed the use of RPCSEC_GSS context handles established in one
program (NFSv4, in the client->server direction) in another (the NFSv4
CB program in the server->client direction).

> HMACs take keys. SSV is the input to HMAC. QED.

Alternate view-point: you need cookies, you don't need HMAC, therefore
you don't need keys and you can call these things just what they are:
cookies.

To understand which is correct I need to understand what's desired.  As
I understand it you want to make it so only the same client that created
a session can add connections to it.  Is that correct?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Apr 2007 14:24:24 -0500

> I'll read it again more closely.

I re-read section 2.10.6.3.

I think it would be a lot simpler to say that:

a) multi-user clients SHOULD (or even MUST) have their own principal 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

b) clients MUST use the same client principal for certain operations as
   were used earleir for related operations (e.g., MUST use the same
   principal for adding connections to sessions that was used when the
   sessions were created).

If the WG really wants to support multi-user clients w/o their own
principal and credentials then we'll need to do something different than
what the I-D proposes or what I propose.  Specifically we'll need a
way to do ephemeral key agreement (e.g., Diffie-Hellman) and bind GSS
authentication to it -- that way there's a way to provide privacy
protection without client credentials even when the mechanism used to
authenticate users is subject to users acting as MITMs between the
client and the server.

One way to do that would be to do what we've been working towards
already (albeit slowly): channel binding to unauthenticated IPsec
channels.  We're making much progress on that.  The BTNS WG is currently
last calling the core unauthenticated IPsec I-D, and my I-D on channel
binding is in IETF LC; the BTNS WG will probably last call other bits
soon as well.

Cheers,

Nico
--

---

From: Mike Eisler <[email-masked]>
Date: Tue, 10 Apr 2007 09:19:25 -0700 (PDT)

>    rather than as a user principal

What it says now:

If a client is assigned a machine principal then the client SHOULD use
the machine principal's RPCSEC_GSS context to privacy protect the SSV
from eavesdropping during the SET_SSV operation. If a machine principal
is not being used, then the client MAY use the non-machine principal's
RPCSEC_GSS context to privacy protect the SSV. The server MUST accept
either type of principal. A client SHOULD change the SSV each time a
new principal uses the session.

----

What you are saying doesn't sound like the same thing. Or if it is,
it doesn't come out that way.

> what the I-D proposes or what I propose.  Specifically we'll need a

Why do we need to do something different?
Explain why what is there won't work.

> way to do ephemeral key agreement (e.g., Diffie-Hellman) and bind GSS

The SSV is a form of ephemeral key agreement.

> binding is in IETF LC; the BTNS WG will probably last call other bits

Depending on IPsec is a nonstarter.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Apr 2007 11:42:51 -0500

> new principal uses the session.

You missed my point.

What exactly is the purpose of SSV, and can it be replaced with
something simpler?

As near as I can tell the purpose of SSV is to decouple authorization of
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 protection
of a multi-user client using the Kerberos V mechanism against active
attacks by its own users.

I don't think the SSV is necessary -- multi-user clients tend to, and,
really, ought to have their own principals (those that don't can
nonetheless cope).

> Explain why what is there won't work.

It's not that it won't work, it's that it's not needed.

> The SSV is a form of ephemeral key agreement.

But it requires privacy protection, whereas ephemeral DH requires only
integrity protection.  And going back to the previous point, the SSV
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 the
secret through eavesdropping, so the user can impersonate the client, b)
this secret is not used to encrypt anything else, so the other users can
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
users?  If so, it's not comprehensive and you need to look at something
else, and I offer one solution; other solutions are possible.  If that
is not the point of SSV, then why does it need to be so complicated, why
not just require that the same initiator that created a session be used
to bind new connections to it and call it a day?

---

From: Mike Eisler <[email-masked]>
Date: Tue, 10 Apr 2007 09:57:28 -0700 (PDT)

--- Nicolas Williams <[email-masked]> wrote:

> > > a) multi-user clients SHOULD (or even MUST) have their own
> principal
> > > and

Or you are missing mine.

> What exactly is the purpose of SSV, and can it be replaced with

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.

> attacks by its own users.

I don't know what you mean, so give an example.

> really, ought to have their own principals (those that don't can

The WG rough consensus is opposed to your opinion.

> > > principal and credentials then we'll need to do something
> different
> > > than

I disagree. Your disagreement comes a little late, so the onus
is on you to make an argument why we should revisit session security
now.

> integrity protection.  And going back to the previous point, the SSV

And apparently IPsec.

> secret through eavesdropping, so the user can impersonate the client,

The user can only impersonate himself. So?

> b)

How?

> 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.

> to bind new connections to it and call it a day?

Because that initiator may have logged off (e.g. done a kdestroy).

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Apr 2007 12:34:33 -0500

> To prevent Mallet from screwing up a session that Bob wants to

It would be simpler to say that if Alice started the session then only
Alice can add connections to it.

> As for simpler, .x file changes are closed, unless there is

Even for removing things?

> Because that initiator may have logged off (e.g. done a kdestroy). 

There's two ways to deal with that: a) tough, restart sessions, b) add a
handover operation.  All of which save you the trouble of having to use
HMAC, having to deal with hash agility, having to analyze the SSV
protocol, ...

---

From: Mike Eisler <[email-masked]>
Date: Tue, 10 Apr 2007 11:15:16 -0700 (PDT)

> Alice can add connections to it.

Yes, and that creates problems when Alice logs off.

> Even for removing things?

If you remove SET_SSV, you change BIND_CONN_TO_SESSION because it
uses a digest derived from the shared key established and
changed by SET_SSV.

> > > is not the point of SSV, then why does it need to be so
> complicated,
> > > why
> > > not just require that the same initiator that created a session
> be
> > > used
> There's two ways to deal with that: a) tough, restart sessions, b)

That's a non-solution with respect to the requirements and with
respect to what we want to achieve with sessions. Restart a session
that implements exactly once semantics with non-idempotent
operations in progress? 

> add a
> handover operation.  All of which save you the trouble of having to

That's a .x file change. Regardless. If Mallet starts the session,
and Alice logs in and uses it, Mallet can mess up Alice until
he logs off/hands over.

SET_SSV is sort of like handover in that it deals with Bob logging
off after he establishes the session, allowing other users, 
to use the session and change the session.

> use

We have to use HMACs for Kerberos anway, and deal with hash agility.
As specified, if you've got an algorithm OID, you can use a better
hash.

> protocol, ...

Analyzing the SSV protocol is an issue, but people have had many
months to look at it. Adding another protocol adds more months
of analysis.