From: Mike Eisler (mike@eisler.com)
Date: 12/20/02-05:59:48 PM Z
Message-ID: <3E03AEF4.3000608@eisler.com>
Date: Fri, 20 Dec 2002 15:59:48 -0800
From: Mike Eisler <mike@eisler.com>
Subject: NFSv4, Kerberos V5, and AES
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
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:45 AM Z CST