Subject: Re: [Ietf-krb-wg] LDAP schema for kdc

From: Howard Chu <[email-masked]>
Date: Thu, 15 Oct 2009 19:24:09 -0700

I've posted a first draft on my web site

http://highlandsun.com/hyc/drafts/draft-chu-ldap-kdc-schema-xx.html
http://highlandsun.com/hyc/drafts/draft-chu-ldap-kdc-schema-xx.xml
http://highlandsun.com/hyc/drafts/draft-chu-ldap-kdc-schema-xx.txt

Since an LDAP schema is actually a work item for this workgroup I presume that 
this document should be renamed/reworked a bit before sending it to the IETF 
rfc-editor for wider dissemination.

But I think it's in good enough shape to serve as a starting point for 
discussion here, and it addresses most of the complaints I've seen regarding 
the existing schemas.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 16 Oct 2009 01:34:56 -0400

--On Thursday, October 15, 2009 07:24:09 PM -0700 Howard Chu 
<[email-masked]> wrote:

> Since an LDAP schema is actually a work item for this workgroup I presume
> that this document should be renamed/reworked a bit before sending it to
> the IETF rfc-editor for wider dissemination.

RFC-Editor doesn't get involved until we have an approved document ready to 
become an RFC.  The internet-drafts repository is managed by a completely 
separate entity(*).

It's entirely appropriate to upload the initial document to the I-D 
repository; see <https://datatracker.ietf.org/idst/upload.cgi>, and I 
encourage you to do so.

-- Jeff

---

From: Andrew Bartlett <[email-masked]>
Date: Fri, 16 Oct 2009 16:34:20 +1100

As I said on IRC, my only objection is to:

> ( KRBATTR.11 
> NAME 'krbExtraData'
>                    EQUALITY octetStringMatch
>                    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
> 
>    This attribute holds arbitrary data that may be needed by a
>    particular implementation.  The values are encoded in ASN.1 DER.
> 
>    ##### The format of the values for this attribute is explained below,
>    ##### ExtraData ::= SEQUENCE {
>    ##### tag       [0] OCTET STRING,
>    ##### data      [1] OCTET STRING
>    ##### }

a void * implementation specific attribute has no place in an internet
specification, particularly one as flexible as LDAP in allowing for
addition of extra attributes by textual name.  Implementations needing
this should define (and publish) their own named octetString attributes
to store them in. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Howard Chu <[email-masked]>
Date: Thu, 15 Oct 2009 22:50:50 -0700

Jeffrey Hutzelman wrote:
> repository; see<https://datatracker.ietf.org/idst/upload.cgi>, and I
> encourage you to do so.

Ok, uploaded.

http://www.ietf.org/internet-drafts/draft-chu-ldap-kdc-schema-00.txt
http://www.ietf.org/internet-drafts/draft-chu-ldap-kdc-schema-00.xml

---

From: Simo Sorce <[email-masked]>
Date: Fri, 16 Oct 2009 08:41:33 -0400

> discussion here, and it addresses most of the complaints I've seen regarding 

I just noticed that in krbKDCInfo there is a krbKeyVersion, I am not
sure that is ideal.
In the krbKeySet there is already a kvno value, shouldn't we use that ?

I'm advocating krbKeySet kvno because we may have multiple master keys
valid at one time. This happens when the Admin wants to change the
master key without taking the database offline.

The admin generates a new master key with the next kvno and save it in
the krbKeySet alongside with the old key, and then slowly proceeds to
re-encrypt the krbKeySets in the database. Both keys need to be
available until all principals have been converted.

When there are 2 keys stored (old and new) what would krbKeyVersion
point to ? The old one? the new one ? And what would it be useful for ?

The mkvno field for the master key is always omitted of course as there
is no master key for the master key :)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: Howard Chu <[email-masked]>
Date: Fri, 16 Oct 2009 12:06:46 -0700

> In the krbKeySet there is already a kvno value, shouldn't we use that ?

You must use both. As the doc says, the krbKeyVersion attribute records the 
current key version number. Every keyset also has a key version number, but 
only the keyset whose kvno matches the value in krbKeyVersion is "current". 
This identifies which key is used in new encryption operations, while 
everything else is "old".

---

From: Simo Sorce <[email-masked]>
Date: Fri, 16 Oct 2009 15:18:09 -0400

> everything else is "old".

Ok I assumed that the "highest" was the current, I guess seen this way
it doesn't hurt to have an explicit setting after all though.

---

From: Howard Chu <[email-masked]>
Date: Sat, 17 Oct 2009 17:40:11 -0700

> discussion here, and it addresses most of the complaints I've seen regarding
Regarding a couple of the extra attributes I tacked on at the end, taken from 
the MIT/Novell schema: the krbPrincNamingAttr and krbPrincContainer are not 
enough info for the envisioned use case. You also need to define a list of 
objectclasses to use for the entry, and you need some way to provide default 
values for any required attributes of those classes. The information required 
to do this properly is certainly outside the scope of a KDC, so it doesn't 
seem particularly practical or useful to worry about it here.

That basically means that LDAP entry creation is always done using LDAP tools, 
and KDC information is either provided in the LDAP tool at creation time or is 
added later by kadmin onto existing LDAP entries.

The krbLDAPURI attribute supersedes the 
krbSubTrees/krbSearchScope/krbLDAPServers attributes from the MIT/Novell 
schema. In general we expect a KDC will only be talking to a local LDAP 
server; allowing for multiple servers is a pretty fringe case. But certainly 
you could expect to see multiple subtrees, and you should not assume that a 
single scope is appropriate for every subtree. In the normal case I would 
expect this attribute to contain just a single value, e.g.
	ldap:///dc=example,dc=com??sub?(objectclass=krbPrincipal)

Even if you have a more compartmentalized DIT, a single value should suffice:
	ldap:///dc=example,dc=com??sub?(&(objectclass=krbPrincipal)(|(entryDN:dnSubtreeMatch:=ou=users,dc=example,dc=com)(entryDN:dnOneLevelMatch:=ou=hosts,dc=example,dc=com)))

But then again, if an entry has the right objectClass, then why should the KDC 
care which specific subtree it came from? When is it ever useful not to just 
do a global subtree search?