From Nicolas.Williams at sun.com  Fri Jan 20 15:19:51 2006
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 20 Jan 2006 14:19:51 -0600
Subject: [kdc-schema] [Kdc-info] Preliminary draft of LDAP Kerberos
	schema
In-Reply-To: <s289154a.059@lucius.provo.novell.com>
References: <s289154a.059@lucius.provo.novell.com>
Message-ID: <20060120201951.GA26500@binky.Central.Sun.COM>

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
-- 


From rnagarajan at novell.com  Tue Jan 31 00:45:09 2006
From: rnagarajan at novell.com (Rajasekaran Nagarajan)
Date: Mon, 30 Jan 2006 22:45:09 -0700
Subject: [kdc-schema] [Kdc-info] Preliminary draft of LDAP Kerberos
	schema
In-Reply-To: <20060120201951.GA26500@binky.Central.Sun.COM>
References: <s289154a.059@lucius.provo.novell.com>
	<20060120201951.GA26500@binky.Central.Sun.COM>
Message-ID: <43DF4672.4E7A.000F.0@novell.com>

Hi Nico:

Thanks very much for your comments. I shall appropriately incorporate
these comments in the draft and post the updated draft soon.

Thanx...
Regards - Raj 
 
>>> Nicolas Williams <Nicolas.Williams at sun.com> 01/21/06 1:49 am >>> 
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
--