From: Nicolas Williams (Nicolas.Williams@sun.com)
Date: 12/20/02-06:09:54 PM Z
Date: Fri, 20 Dec 2002 16:09:54 -0800 From: Nicolas Williams <Nicolas.Williams@sun.com> Subject: Re: NFSv4, Kerberos V5, and AES Message-ID: <20021220160954.L1041@binky.central.sun.com> On Fri, Dec 20, 2002 at 03:59:48PM -0800, Mike Eisler wrote: > 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. 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. > 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. 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). > 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. 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 --
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:45 AM Z CST