From: Nicolas Williams (Nicolas.Williams@sun.com)
Date: 12/23/02-10:18:31 AM Z
Date: Mon, 23 Dec 2002 08:18:31 -0800 From: Nicolas Williams <Nicolas.Williams@sun.com> Subject: Re: NFSv4, Kerberos V5, and AES Message-ID: <20021223081830.H16688@binky.central.sun.com> On Fri, Dec 20, 2002 at 04:09:54PM -0800, Nicolas Williams wrote: > 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. 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 --
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:46 AM Z CST