Subject: crypto performance and RPCSEC_GSS

From: Mike Eisler <[email-masked]>
Date: Fri, 20 Dec 2002 15:26:30 -0800

RPCSEC_GSS was conceived with at least two
assumptions:

    - connection time only authentication just isn't good enough.
        First, RPCSEC_GSS may not be running over a transport that has
        connections, and second, hijacking of TCP connections was even in
        those days a well developed craft.

    - host-based authentication, such as what one gets from
        IPsec, is not good enough, because it does nothing to
        cure the obvious security exposures of AUTH_SYS.

So RPCSEC_GSS continued the tradition of AUTH_DH
(AUTH_DES), and offered per RPC authentication, as well
integrity and privacy to protect the payload.

There are costs to per-message security though.
Several years ago I did some measurements.

See
    http://www.connectathon.org/talks99/mre.pdf

slides 9 and 10. In summary, using 270 Mhz ultra sparcs,
100baseT, straight krb5 (no integrity, no privacy),
software crypto cost an additional 1% of CPU, and degraded throughput
(relative to AUTH_SYS), by 2.6%. So, if we had a medium
100X faster, then it would be 100% of the CPU, and degradation
of 260%. I don't think the hardware I worked with in 1999
is indicative of what I could have achieved with Sun's highest
end gear, and in any case, Sun's best stuff (according to
http://www.spec.org/cpu2000/results/res2002q4/ is
half the speed of Intel's and AMD's best). Let's
say that today one could find CPUs 20X
faster then what I tested with in 1999. So
on 10G media, I'm projecting a 5% CPU cost for
basic authentication, and a throughput degradation of 13%.
Moore's law will of course improve this, but if
we assume that network media speeds will continue to
improve at a rate better than Moore's law, we have
to consider other approaches ... we will hit a wall
eventually.

It has been observed (by Nicholas Williams today for example,
and I believe this is the assumption of the DAFS protocol)
that if you believe the network connection is secure, then
authenticating the user once, rather than every message, is
sufficiently secure. Various people have different opinions on
what it means to secure the connection. Personally, I think
means applying cryto to every byte at a level below RPCSEC_GSS.
But if this is done in software, one is no better off than with
RPCSEC_GSS integrity and privacy. So it would need to be done
in hardware, and practically speaking, it is at the IP/IPsec
level that hardware crypto for streams is getting the most
attention.

So what does this mean for the wg's current portfolio of
upper layer protocols? For NFSv4, I observe (actually
Dave Noveck did in a private email, but I'm taking
it a step further than Dave)the following. Assume the
NFSv4 server can detect that IPsec is being applied to
the data stream (presumably there, or could be, APIs
to indicate this).After a particular principal has authenticated
once with RPCSEC_GSS over kerberos or spkm, or any other secure
mechanism, it could then return WRONGSEC on subsequent accesses by that
principal in order to get it to downgrade security to a flavor that is
less CPU intensive. The lightweight flavor could be AUTH_SYS or it could be
a new, simple mechanism (under the GSS-API)
that simply has the NFSv4 string-based uid as an identifier.
Given that AUTH_SYS doesn't offer a global uid space,
a string-based flavor might be better. I would think that if the wg
pursues NFS on RDDP, we'd want to this new, lightweight flavor.
Note that no protocol changes to NFSv4 are required.

For the replication/migration protocol, we don't even
need the lightweight "name" mechanism. Since
we appear to have reached consensus that there will be just one session
per transport connection, then at session creation time we would use
a secure mechanism that identifies the source and target,
and, if the target believes the connection to be secure,
negotiate down to AUTH_NONE. We might as well use something
resembling SECINFO.

    -mre

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 20 Dec 2002 15:41:40 -0800

> Note that no protocol changes to NFSv4 are required.

Good stuff.  But I think that the lightweigth auth flavor need only
reference already-established GSS contexts, perhaps by naming the
initiator principal name, say.  I don't think we should use AUTH_SYS at
all for this purpose, no way, because the server is already mapping the
GSS initiator principal names to its internal identifiers and we must
preserve the server's ability to do so, whereas AUTH_SYS would take it
away (and besides, the server would have to ensure that the AUTH_SYS
data is valid for some established GSS context every time or use it as a
GSS context lookup key - messy, messy).

>     -mre

Nico
--

---

From: Brent Callaghan <[email-masked]>
Date: Fri, 20 Dec 2002 16:26:50 -0800

Mike Eisler wrote:
> :
 > :

If connection-based security is appropriate for a repl-mig
protocol then it would be more appropriate to use a connection
based standard like SASL, rather than transaction-oriented
security of RPCSEC_GSS.

BTW: another example of a XDR-based protocol that uses
async messaging: NDMP.

	Brent

---

From: Mike Eisler <[email-masked]>
Date: Fri, 20 Dec 2002 16:55:36 -0800

> protocol then it would be more appropriate to use a connection 

Connection-based security is only appropriate if the connection
is secure. My proposal lets one use RPCSEC_GSS
to work with secure or not secure connections. Also, I'm,
assuming ONC RPC framing, and since ONC-RPC defines
authentication at the RPC level, RPCSEC_GSS is most
appropriate. If we aren't using ONC RPC
framing in the repl-mig protocol,  then RPCSEC_GSS
is clearly inappropriate. Without ONC RPC framing, and
with IPsec connection security, I agree that SASL over GSS-API
(context setup phase only) is the way to go.

    -mre