From Nicolas.Williams at sun.com  Wed May 31 15:35:13 2006
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 31 May 2006 14:35:13 -0500
Subject: [Kdc-info] Preliminary draft of LDAP Kerberos schema
In-Reply-To: <43DF4672.4E7A.000F.0@novell.com>
References: <s289154a.059@lucius.provo.novell.com>
	<20060120201951.GA26500@binky.Central.Sun.COM>
	<43DF4672.4E7A.000F.0@novell.com>
Message-ID: <20060531193513.GM11607@binky.Central.Sun.COM>

On Mon, Jan 30, 2006 at 10:45:09PM -0700, Rajasekaran Nagarajan wrote:
> Hi Nico:
> 
> Thanks very much for your comments. I shall appropriately incorporate
> these comments in the draft and post the updated draft soon.

Well?

BTW, MIT is getting close to shipping and I'm concerned.  I'm
particularly concerned about the lack of versioning of the krbSecretKey
attribute, the 16-bit kvno, the lack of a master key vno, etc...

I think MIT ought to fix this now if at all possible.  If there exist
deployments of this schema then rename krbSecretKey now and fix its
contents' format.

To restate my suggestion, with the addition of a format version number
and better extensibility:

      First 2 bytes     Major format version number
      Next  2 bytes     Minor format version number
      Next  4 bytes     Version number (kvno) of this key
      Next  4 bytes     Version number of the master key (K/M kvno) used
                        to encrypt the following data
      <encrypted data>

      The <encrypted data> octets are to be the output of the RFC3961
      encrypt() function (which provides integrity protection in
      addition to confidentiality protection)  applied to data whose
      format is given below using the master key named by the item
      above:

      First 4 bytes     Version number of this key
      First 2 bytes     Length of principal name (princNameLength)
      Next  2 bytes     Number of keys for the principal (noOfKeys)

      <key/salt types (2 or 4 bytes?) / lengths (2 bytes)>

      <"unparsed" principal name (RFC1964 format)>

      <key/salt values (octet strings of lengths given above)>

      <unknown extra data to be ignored, like ASN.1 extensibility marker>

The format major version number should be incremented for backwards
incompatible format changes; the formatminor version number should be
incremented for backwards compatible format changes (extra data added at
the end).

Nico
-- 


From Nicolas.Williams at sun.com  Wed May 31 15:53:00 2006
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 31 May 2006 14:53:00 -0500
Subject: [Kdc-info] More comments (Re: Preliminary draft of LDAP Kerberos
	schema)
In-Reply-To: <20060531193513.GM11607@binky.Central.Sun.COM>
References: <s289154a.059@lucius.provo.novell.com>
	<20060120201951.GA26500@binky.Central.Sun.COM>
	<43DF4672.4E7A.000F.0@novell.com>
	<20060531193513.GM11607@binky.Central.Sun.COM>
Message-ID: <20060531195300.GB1083@binky.Central.Sun.COM>

I think attributes for recording the time of the last good and bad AS
exchange pre-authentication would be good, and password-based vs.  other
pre-auth mechanisms should be distinguished.

I don't think there should be a bad login count attribute though as I
don't see how it can be safely incremented/reset in a *portable* (w.r.t.
DSes, which I'm sure MIT would want) way given DSes that do multi-master
replication.  I think that N-strikes-you're-locked (even with timeouts)
is a misguided feature, but customers ask for it, so a safe way (or
close to it) of counting bad logins may yet be needed; I do believe this
is feasible, I even think I know how to accomplish this.  The KDC schema
should address this.

Meanwhile, code currently enabled at compile time when
KRBCONF_KDC_MODIFIES_KDB is defined should instead be enabled
at runtime when the KDB supports multi-master replication.

Nico
--