Subject: [Ietf-krb-wg] I-D Action:draft-ietf-krb-wg-kdc-model-00.txt

From: [email-masked]
Date: Mon, 10 Dec 2007 13:10:01 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Kerberos Working Group of the IETF.

	Title           : An information model for Kerberos version 5
	Author(s)       : L. Johasson
	Filename        : draft-ietf-krb-wg-kdc-model-00.txt
	Pages           : 19
	Date            : 2007-12-10

This document describes an information model for Kerberos version 5
from the point of view of an administrative service.  There is no
standard for administrating a kerberos 5 KDC.  This document
describes the services exposed by an administrative interface to a
KDC.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kdc-model-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-krb-wg-kdc-model-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-krb-wg-kdc-model-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Howard Chu <[email-masked]>
Date: Mon, 10 Dec 2007 10:29:31 -0800

> describes the services exposed by an administrative interface to a

That's pretty good. We also need a spec for an LDAP schema; I've been working 
with the Samba team on a draft for that. We have a few problems with the 
schemas currently in use for the MIT and Heimdal KDCs (aside from the obvious 
fact that they use two different schema) and have a proposal on how to unify 
them. Will be publishing the first draft soon.
--    -- Howard Chu
    Chief Architect, Symas Corp.  http://www.symas.com
    Director, Highland Sun        http://highlandsun.com/hyc/
    Chief Architect, OpenLDAP     http://www.openldap.org/project/

-- 
   -- Howard Chu
   Chief Architect, 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: Howard Chu <[email-masked]>
Date: Mon, 10 Dec 2007 10:29:51 -0800

> describes the services exposed by an administrative interface to a

Section 6.4.1.3, policyContent - this is actually one of the big problems with 
the existing LDAP KDC schemas, IMO. There is no excuse for using opaque blobs 
anywhere in a system based on ASN.1. At the very least, this should be a DER 
Sequence, leaving room for specifics to be defined later. The point is that 
all data should be parseable, even if not completely usable, by any software 
agent that encounters it. (And punting by use of OctetString within the DER 
encoding should be heavily discouraged.)

--    -- Howard Chu

---

From: Leif Johansson <[email-masked]>
Date: Mon, 10 Dec 2007 19:40:40 +0100

> them. Will be publishing the first draft soon.

I guess the wg would be happy to se this since it is one of the
charter items (an ldap schema). Looking forward to it!

    Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Mon, 10 Dec 2007 20:09:17 +0100

> encoding should be heavily discouraged.)
Remember that the information model is an abstract model, not
tied to ASN.1, XSL, OWL or any other schema language. Given
that you are not allowed to mention any specific technology
can you suggest language :-) ?

    Cheers Leif

---

From: Howard Chu <[email-masked]>
Date: Mon, 10 Dec 2007 12:33:06 -0800

> can you suggest language :-) ?

Hm... Ok. But the entire document is implicitly based on attribute-value 
pairs; this notion needs to be stated explicitly. And that of course implies a 
certain range of suitable technologies.

Perhaps it would be better to acknowledge that policy is more complex than a 
simple attribute-value pair can capture, and needs to be expressed as an 
object in its own right. The attributes relevant to a policy object are not 
addressed here. We could define a set of base policy attributes, and note that 
implementations can/should implement a superset of this base set.
-- 
   -- Howard Chu
   Chief Architect, 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: Nicolas Williams <[email-masked]>
Date: Mon, 10 Dec 2007 15:24:21 -0600

> encoding should be heavily discouraged.)

Opaque is not quite the correct description.

policyIdentifier/policyContent is a *typed hole*.

We need typed holes, else we could only extend the model (schema,
modules, protocols, whatever) by Protocol Action updating the base RFC.
That is unacceptable.  This is why we have typed holes in so many
protocols.

Also, we encourage the use of OCTET STRING to build typed holes, rather
than discourage it.

Nico

---

From: Leif Johansson <[email-masked]>
Date: Mon, 10 Dec 2007 22:43:18 +0100

Howard Chu wrote:
> Hm... Ok. But the entire document is implicitly based on
> attribute-value pairs; this notion needs to be stated explicitly. And
> that of course implies a certain range of suitable technologies.
Actually it is based on the notion of an Ontology - i.e something which
has the
semantic power of UML class models essentially. If this wasn't the IETF I'd
have done a UML or OWL model. But this is the IETF and we don't have a
preferred modeling language so its English.
>
> Perhaps it would be better to acknowledge that policy is more complex
> than a simple attribute-value pair can capture, and needs to be
> expressed as an object in its own right. The attributes relevant to a
> policy object are not addressed here. We could define a set of base
> policy attributes, and note that implementations can/should implement
> a superset of this base set.
Exactly what I was trying to do by saying its an opaque type. I couldn't
think of
any common attributes at the time but please help me understand why I was
wrong :-)

    Cheers Leif

---

From: Howard Chu <[email-masked]>
Date: Mon, 10 Dec 2007 13:48:24 -0800

> Also, we encourage the use of OCTET STRING to build typed holes, rather

If it were actually *typed* then I wouldn't have any objections. Just as in 
LDAP, the spec leaves Controls and Extended Operations open to future 
expansion; but each new extension is explicitly tagged with an OID so that 
even if your software doesn't understand the extension, it can still parse it 
and propagate it. It's still possible for someone to inspect it and make sense 
of it. Naked octet strings yield no information whatsoever, and make 
portability and interoperability next to impossible.
-- 
   -- Howard Chu
   Chief Architect, 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: Nicolas Williams <[email-masked]>
Date: Mon, 10 Dec 2007 16:00:57 -0600

> Also, we encourage the use of OCTET STRING to build typed holes, rather

And the reason for that, in ASN.1 modules, is that it's easier to
implement than ANY DEFINED BY (1994 syntax) or the IOS :)
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Mon, 10 Dec 2007 23:02:46 +0100

> If it were actually *typed* then I wouldn't have any objections. Just as in 
But it is typed - the policyIdentifier is the type.
  
    Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 Dec 2007 16:14:54 -0600

> If it were actually *typed* then I wouldn't have any objections. Just as in 

It *is* typed (the type is stored in policyIdentifier).
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Howard Chu <[email-masked]>
Date: Mon, 10 Dec 2007 16:15:37 -0800

> It *is* typed (the type is stored in policyIdentifier).

Oh. OK, that makes sense. It wasn't clear to me that the two attributes were a 
tuple.