Subject: NFSv4, Kerberos V5, and AES

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

I recently re-subscribed after a three year absence to the
krb5 wg alias to see what's been happening, in particular
the progress in migrating from DES (bad for software)
to AES. Things seem to be moving along, but I wanted
to give the nfsv4-wg a heads up about the approach
being taken to add AES to the Kerberos V5
GSS-API mechanism (RFC 1964).

Basically, other than adding some algorithm encodings
for AES to the RFC 1964 GSS-API tokens,
there will be little change. The idea is that if KDC,
a client, and a server are upgraded to support
AES, and if the client gets a ticket that uses the new
AES encryption type, then NFSv4 over krb5/aes will
just work. Since the NFSv4 SECINFO stuff uses a
QOP value of zero for krb5, the default QOP ends up being
that which corresponds to the ticket's encryption type.
This is model is very advantageous to
the nfsv4 wg because it means there's no protocol
specification work.

However, what it does mean is that there is no way
within the NFSv4 protocol to negotiate/distinguish
krb5/aes instead of krb5/des (the converse is also true,
but it would be irrational to prefer a slower, less secure
algorithm to AES). We would have to rely on the
system administrator to ensure that AES is configured
properly everywhere. So if a client for some reason
asked for the des encryption type, that's what would be
used even if the server was AES capable, and the
system administrator would not be aware.

I made these arguments, mostly as a devil's advocate,
to the krb5 wg, and didn't get much sympathy.
There are technical issues with Kerberos that
make my arguments somewhat moot. As captured
by Martin Rex:

    PKI-based mechanisms (e.g. SPKM, but also crypto-protocols that
    perform a key exchange more like SSL) have separated key exchange
    (or the establishment of a shared keying material) from the actual
    encryption algorithms (ciphersuites) that are going to be used,
    and in that situation QOP values are ok and could be used
    like ciphersuites in SSL.

    However current Kerberos seems to have the key exchange tightly
    coupled with the encryption type, so that the selection/negotiation
    will have to be performed during "security context establishment".
    QOP values can only be passed to the message protection calls,
    and that is far too late to give the gssapi mechanism a clue what
    an application desires.

In other words, it is an RFC1510 problem, not an RFC1964
problem.

We *could* specify a new Kerberos V5 security mechanism
that mandates AES as the default QOP. (I suggested that
too, and didn't get much sympathy). If the key exchange from the
client indicated non-AES, then the key exchange would then
fail, and so the NFS user experiences an
explicit failure rather than silently using DES.
I don't really want to go there though .. more gss-api
mechanisms is more complexity.

If there are nfsv4 implementors that care about this, and if
they control their RFC1964 implementations, they can
always add API extensions to enforce AES. Personally,
I like the simplicity of making this under control of
the realm administrator, which is effectively what the
krb5 wg is advocating.

    -mre

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 20 Dec 2002 16:09:54 -0800

> In other words, it is an RFC1510 problem, not an RFC1964

IMO, it's an RFC1964 problem since it could surely specify to use
session encryption types unrelated to the session key exchanged with
Kerberos, provided that it specified the necessary key transformations.

TLS does this in the Kerberos case, so RFC1964 could have as well.

The problem is that it may be too late to replace RFC1964.

IMO we could produce a replacement to RFC1964, using the same OID, and
let the Kerberos ticket session key enctype be used to determine which
version of RFC1964 to use.  In fact, something like this is what will
happen, but it won't go far enough that the session encryption might be
specified separately from the ticket session key enctype.

> mechanisms is more complexity.

No, the sysadmin has the ability to specify what Kerberos/RFC1964
enctypes are to be used with RPCSEC_GSS via the enctypes available for
the NFS service principal names.  As a consequence the sysadmin must
make this choice globally to each server, rather than locally to each
share, but it's hardly as if that will make much difference, as long as
the only enctypes available for RFC1964 remain DES and AES (or, rather,
DES, 3DES, RC4 and AES).

> the realm administrator, which is effectively what the

I don't see how implementors could do this any other way.  They don't
have a choice as the choice has been made for them by RFC1964, and it
was made long ago.

>     -mre

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Dec 2002 08:18:31 -0800

> TLS does this in the Kerberos case, so RFC1964 could have as well.

I thought I should expand on this briefly.

Kerberos V negotiates AP exchange session and sub-session key enctypes
in the KDC exchanges.  It is possible to make different session keys
from the keys negotiated by Kerberos V exchanges, but this probably
didn't seem very sensible way back when (I'm speculating here) and, in
any case, the lack of perfect forward security (PFS) does not really
encourage the use of strong keys negotiated with weak keys.

Extensions to Kerberos V have been proposed which will, in fact,
facilitate the addition of PFS to Kerberos key exchanges in the AP
exchange, which will then divorce the actual session key strength from
the ticket's session key strength.  These same extensions will also
facilitate the addition of session key derivation and enctype
negotiation to the AP exchange as well.  And in one round trip too.

Thus RFC1964 and its future extension will inherit, from extended
Kerberos V, the ability to negotiate QoPs.

The proposed extensions to Kerberos V negotiate support for new or old
Kerberos in the KDC exchanges as well, just as Kerberos V today
negotiates ticket session key enctypes, and therefore AP exchange
sub-session key enctypes, in the KDC exchanges.

In a way, RFC1964's lack of support for QoP negotiation derives from the
limitations of RFC1510.  And note that TLS/Kerberos V will have to be
re-specified, since the TLS/Kerberos suite does not use AP-REQ/AP-REP
messages (it makes its own) and so won't inherit the wonderful new
features of extended Kerberos V.

Cheers,

Nico
--