From kgokulavasan at novell.com Thu Aug 3 07:52:35 2006 From: kgokulavasan at novell.com (K.G. Gokulavasan) Date: Thu, 03 Aug 2006 05:52:35 -0600 Subject: [kdc-schema] Version 1 draft of LDAP Kerberos schema Message-ID: <44D22FAA.42B1.00F1.0@novell.com> Hi, Thanks to all those people who provided comments on the initial version. I have attached the updated draft (Version 1). Please provide your comments. Regards, Gokul -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: draft-rajasekaran-kerberos-ldap-schema-01.txt Url: http://mailman.mit.edu/pipermail/kdc-schema/attachments/20060803/caceb865/attachment.txt From raeburn at MIT.EDU Fri Aug 4 02:31:41 2006 From: raeburn at MIT.EDU (Ken Raeburn) Date: Fri, 4 Aug 2006 02:31:41 -0400 Subject: [kdc-schema] [Kdc-info] Version 1 draft of LDAP Kerberos schema In-Reply-To: <44D22FAA.42B1.00F1.0@novell.com> References: <44D22FAA.42B1.00F1.0@novell.com> Message-ID: 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 From kgokulavasan at novell.com Fri Aug 4 08:42:51 2006 From: kgokulavasan at novell.com (gokul) Date: Fri, 04 Aug 2006 18:12:51 +0530 Subject: [kdc-schema] [Kdc-info] Version 1 draft of LDAP Kerberos schema In-Reply-To: References: <44D22FAA.42B1.00F1.0@novell.com> Message-ID: <1154695371.5985.2.camel@gokul.blr.novell.com> 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.