[37036] in Kerberos
Re: Issue with kvno
daemon@ATHENA.MIT.EDU (Nico Williams)
Mon Jun 1 18:46:21 2015
Date: Mon, 1 Jun 2015 17:45:57 -0500
From: Nico Williams <nico@cryptonector.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <20150601224556.GB17122@localhost>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.GSO.1.10.1506011402350.22210@multics.mit.edu>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Mon, Jun 01, 2015 at 02:11:32PM -0400, Benjamin Kaduk wrote:
> On Fri, 29 May 2015, vishal wrote:
> > My question is that why kvno is not always present in ticket and this
> > ticket is basically which comes in TGS-RESP(from home domain) and sname is
> > krbtgt for trusted domain in TGS-REQ.
> The kvno field in the ASN.1 EncryptedData type is an optional field, used
> to assist the recipient in selecting which key to use to decrypt the data.
The kvno is not required, therefore it may be missing. Active Directory
does not keep track of key version numbers, which is why you see kvno
missing when using AD.
When a service gets an AP-REQ with a Ticket that has no kvno, then the
service has to do something like:
- try the newest kvno
and/or
- try every key with the same enctype
Actually, one has to do the latter because of key rollover and KDC
replication latency issues.
That AD does not keep track of key history is mostly not a problem,
except for changing cross-realm keys. For cross-realm key rollover the
lack of key history basically necessitates an outage.
Nico
--
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
