[kdc-schema] [Kdc-info] Version 1 draft of LDAP Kerberos schema

[gokul]

On Fri, 2006-08-04 at 02:31 -0400, Ken Raeburn wrote:
> Some quick notes:
> 
> First: The referrals draft is in the references section, but I can  
> find no reference to it.  Does this draft support data describing  
> referrals?  Likewise, Donna Skibbie's draft seems to be mentioned  
> only in the references section.
> 

I will split the References section into Normative and Informative and
update the draft accordingly.

> Second: I don't see where we could store the string-to-key parameters  
> that may be needed to generate the ETYPE-INFO2 message (e.g., PBKDF2  
> iteration count for AES).  If it's not stored somewhere as an octet  
> string, the form of the data would depend on the encryption type of  
> the key.
> 

I will get back on this.

> In fact, there's no explanation for the KrbSalt structure at all.  If  
> the "type" field is meant to represent one of the types  listed under  
> krbSupportedSaltTypes, then I suggest the salt string should be  
> optional, because for some (most?) of those types, the type (in  
> combination with the principal or realm name) indicates the salt  
> string to be sent, or even a non-salt padata type to be used  
> instead.  E.g., "onlyrealm" is a shorthand indicating that for  
> principal joe at FOO.COM, the salt string is FOO.COM instead of  
> FOO.COMjoe as would normally be used.  In fact, I'm not sure there's  
> more than one salt type for which having the string makes sense.   
> Perhaps for redundancy or convenience -- but if you have the string,  
> and use it, the distinctions between some of the salt types vanish.
> 

Yes. You are right. The "type" field in KrbSalt structure is meant to
represent one of the krbSupportedSaltTypes. I will update the draft with
explanation for both KrbSalt structure and EncryptionKey structure.

It makes sense to make the "salt" field in KrbSalt structure as optional
and it can be left to the implementation, to store it or generate it.

> In 3.8 (krbTicketFlags) you refer to pages 67 and 75 of RFC 4120, but  
> I don't see where RFC 4120 discusses such things as PWCHANGE_SERVICE,  
> for example.  And what should an implementation do if flags are set  
> that are not listed in this section?  Report an error, since they may  
> indicate a new restriction not known to the implementation?  Ignore  
> them?  (True, we're specifying a schema, not implementation behavior,  
> but the relevant point is what kind of future extensions might be  
> allowed for bits in this field.)
> 

Some of the flags and all the values are derived from MIT
implementation.

There is a very good possibility when we extend this in future, some of
the bit fields may overlap with implementation specific extensions. So
how about reserving some bit fields for the standards (for e.g., 6 bits
can be reserved for standards (0x00000001 - 0x00800000) and the
remaining 2 bits can be used for implementation specific extensions)?

Regards,
 Gokul.