headers
Nicolas Williams | 6 Apr 2007 18:47
Picon

SSV is a cookie, not a key; why bother with HMAC?

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?
(Continue reading)

Permalink | Reply | 8 comments |
headers
Mike Eisler | 6 Apr 2007 19:01
Picon
Favicon

Re: SSV is a cookie, not a key; why bother with HMAC?


--- Nicolas Williams <Nicolas.Williams <at> sun.com> wrote:

> 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

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.

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

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.

>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Tom Beglin | 7 Apr 2007 20:07
Picon
Favicon

Tom Beglin/Tucson/IBM is out of the office.

I will be out of the office starting 04/02/2007 and will not return until 04/09/2007.

I am out of the office until Monday April 10. For N series interoperability issues, please contact Matt Krill.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 0 comments |
headers
Nicolas Williams | 9 Apr 2007 21:24
Picon

Re: SSV is a cookie, not a key; why bother with HMAC?

On Fri, Apr 06, 2007 at 01:22:30PM -0500, Nicolas Williams wrote:
> On Fri, Apr 06, 2007 at 10:01:12AM -0700, Mike Eisler wrote:
> > --- Nicolas Williams <Nicolas.Williams <at> sun.com> wrote:
> > > agreement, and no pre-shared keys.  The whole thing depends on
> > > 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.
> 
> 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
--

-- 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 5 comments |
headers
Mike Eisler | 10 Apr 2007 20:15
Picon
Favicon

Re: SSV is a cookie, not a key; why bother with HMAC?


--- Nicolas Williams <Nicolas.Williams <at> sun.com> wrote:

> On Tue, Apr 10, 2007 at 09:57:28AM -0700, Mike Eisler wrote:
> > > 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.
> 
> It would be simpler to say that if Alice started the session then
> only
> Alice can add connections to it.

Yes, and that creates problems when Alice logs off.

> 
> > As for simpler, .x file changes are closed, unless there is
> > a compelling reason.
> 
> 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.

> 
> > > 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?
> > 
> > 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)

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
> HMAC, having to deal with hash agility, having to analyze the SSV

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.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 0 comments |
headers
Nicolas Williams | 10 Apr 2007 19:34
Picon

Re: SSV is a cookie, not a key; why bother with HMAC?

On Tue, Apr 10, 2007 at 09:57:28AM -0700, Mike Eisler wrote:
> > 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.

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
> a compelling reason.

Even for removing things?

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

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 1 comment |
headers
Mike Eisler | 10 Apr 2007 18:57
Picon
Favicon

Re: SSV is a cookie, not a key; why bother with HMAC?


--- 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 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
> > 
> > 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.
> 
> 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
> 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 know what you mean, so give an example.

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

The WG rough consensus is opposed to your opinion.

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

> 
> > > way to do ephemeral key agreement (e.g., Diffie-Hellman) and bind
> GSS
> > 
> > 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

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
> the
> secret through eavesdropping, so the user can impersonate the client,

The user can only impersonate himself. So?

> b)
> this secret is not used to encrypt anything else, so the other users
> can
> still actively attack the client.

How?

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

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

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 2 comments |
headers
J. Bruce Fields | 10 Apr 2007 22:48

Re: Some locking issues in draft-minorversion1-10 ?

On Tue, Apr 10, 2007 at 04:00:43PM -0400, Talpey, Thomas wrote:
> I noticed some inconsistencies in the draft while investigating the
> descriptions of mandatory versus advisory locking.

A basic question: does anyone implement mandatory locking over NFS?  If
so, has it been used?

--b.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 1 comment |

Gmane