[kdc-schema] [Kdc-info] Preliminary draft of LDAP Kerberos schema

[Nicolas Williams]

Comments:

 - krbPrincipalName's value cannot be determined from RFC4120 (successor
   of RFC1510) alone as it provides no string encoding of principal
   names (these being structured data).

   Instead reference the encoding described in RFC1964, section 2.1.1.

 - In general references to RFC1510 need to be upgraded to RFC3961 or
   RFC4120, and, in a handful of places, as mentioned above, corrected
   to be references to RFC1964.

 - What's the harm of having krbPrincipalType be an attribute of
   krbPrincipalAux also?  It may be useful to allow it.

 - The more I think about it the more I think it worthwhile to separate
   the list of enctypes supported by a principal for ticket session keys
   from the list of long-term keys for that principal.

   So I think a separate (optional) attribute for listing the enctypes
   supported by a principal's software (invariably these will be
   principals tightly related to host, typically host-based principals).

   KDCs should compute the actual set of enctypes supported by a a
   principal's software as the union of the entypes listed in such an
   attribute and the enctypes for which the principal has long-term
   keys.

 - krbSecretKey value format doesn't specify which parts are encrypted,
   but it's clear that the intention is not to encrypt all of it, else
   why have the master key vno in there?

 - All of each krbSecretKey value EXCEPT the master key vno should be
   encrypted (with the RFC3961 encrypt() function, that is, integrity
   protected).  Also, it would be very useful to have the kvno in the
   clear, to quickly select the latest key.

 - Two bytes is not really enough for key version numbers, as I recall.

 - So, I think you might want to rearrange the krbSecretKey value format
   as follows:

      First 4 bytes     Version number of this key
      Next  4 bytes     Version number of the master key 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)
      [...]

      (And here, again, where the principal name is placed the encoding
      referenced above should be used.)

 - The rationale for putting the time of last password/key change time
   in the krbSecretKey encrypted data should be described.

Cheers,

Nico
--