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

[Ken Raeburn]

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.

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.

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.

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

Ken