Coda File System

AFS tokens and kerberos 5

From: Greg Troxel <>
Date: Tue, 27 Aug 2002 09:21:40 -0400
I am not fully clear on the details below of the AFS changes for
kerberos 5, but I thought it would be helpful for coda folks to be
aware of what's going on (it was news to me).

------- Forwarded Message

>From  Mon Aug 26 13:40:18 2002
Return-Path: <>
Received: from (PCH.MIT.EDU [])
	by (Postfix) with ESMTP id 83F4C3C36
	for <>; Mon, 26 Aug 2002 13:40:18 -0400 (EDT)
Received: from (localhost [])
	by (8.9.3+Sun/8.9.3) with ESMTP id NAA07907;
	Mon, 26 Aug 2002 13:32:48 -0400 (EDT)
	by (8.9.3+Sun/8.9.3) with ESMTP id NAA07874;
	Mon, 26 Aug 2002 13:31:07 -0400 (EDT)
Received: from (KONISHI-POLIS.MIT.EDU [])
	by (8.9.2/8.9.2) with ESMTP id NAA14135;
	Mon, 26 Aug 2002 13:31:07 -0400 (EDT)
Received: by (Postfix, from userid 8042)
	id 546AF151FEF; Mon, 26 Aug 2002 13:31:05 -0400 (EDT)
Subject: Is this too big of a change?
Message-Id: <>
From: (Sam Hartman)
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <>
List-Post: <>
List-Subscribe: <>,
List-Id: The Kerberos Authentication System Mailing List <>
List-Unsubscribe: <>,
List-Archive: <>
Date: Mon, 26 Aug 2002 13:31:05 -0400 (EDT)

Hi.  We're working on 1.2.6beta2 and are proposing to make a change
that has somewhat more impact than we would normally make in a point
release and we'd like to see how much trouble it would create for

The OpenAFS and Arla community is working on support for somewhat more
native krb5  authentication to AFS.  Servers will support the
encrypted part of a krb5 ticket sent with a special kvno as  an AFS
token.  It turns out that if you have a special krb524d this
improvement allows you to upgrade to doing krb5 AFS without any client

We're going to roll support for this change into the 1.2.6 krb524d.
The question is:  how should we determine if  we use the new style
tickets  or whether we just issue krb44 tickets as before.

The AFS community seems ready to push fairly hard for upgrades to this
new technology and (when it is ready later, RXGSS) so we'd like to
help them by making the default for afs principals be the new
format--optimizing for future convenience at the expense of
transition-time inconvenience.  We plan to default to the new format
afs principals with an exception list of afs principals that should
receive normal krb4 tickets.

This means that if you were to deploy 1.2.6 today, you'd have to
create an exception list for any afs cells your KDC serves.

Does anyone believe this is too much work for sites to do when
deploying 1.2.6?  I'm much more interested in reports that this
actually would be a problem than reports of how this might be a
problem for a hypothetical third party or how I could do something


- --Sam

Kerberos mailing list 

------- End of Forwarded Message
Received on 2002-08-27 11:33:48