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

From: [email-masked]
Date: Sun, 7 Mar 2010 03:00:01 -0800 (PST)

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. Johansson
	Filename        : draft-ietf-krb-wg-kdc-model-07.txt
	Pages           : 19
	Date            : 2010-03-07

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-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Greg Hudson <[email-masked]>
Date: Sun, 07 Mar 2010 19:27:03 -0500

Semantic comments:

6.1.1.1 makes the incorrect assumption that salts are necessarily
derived from principal names.  If an implementation randomly generates
explicit salts for all principals, it does not need to designate a
canonical principal name for salting.

6.1.1.1 does not say whether a principalName includes a realm name.
Consider the implications for cross-realm TGT principals given that
principalNames must be unique identifiers within the model.

6.1.1.14 creates some further alarming implications: that the model is
not necessarily limited to a single realm, but that principal names must
be unique independent of what realms they live in.  Moreover, while I
could understand a desire to "link" principals by having a single
principal object live in more than one realm, I think that's a dangerous
direction for the model to go in.  If principals are "linked" between
multiple realms, do they necessarily have the same name in each realm?

The second paragraph of section 6.2 seems confused.  "If a server
supports an enctype" seems to be about the server in general, but the
sentence goes on to talk about "the principal in question."  Surely a
KDC would still be said to "support" AES even if it contains a principal
containing only a DES3 key.

6.1.2 would be clearer if it briefly mentioned why there might be
multiple KeySets associated with a principal (key rollover situations).

6.2.3 talks about separating the KeySet from the principal "for
security," but doesn't explain why the separation introduces any
security.  Perhaps because it means keys won't necessarily be
transmitted if a principal is retrieved, in an implementation where
objects are retrieved in blobs?

6.1.1.2	and friend introduce similar concepts to 6.3.1.5 and friends,
but use rather different requirements languages.  6.3.1.5 appears to be
trying to impose a requirement on the KDC implementation (a body of
code), while 6.1.1.2 confines itself to imposing requirements on the
model implementation (a standard document).

6.4.1.4 does not define what the "applicability of a policy" means.

7.3 makes what I'd consider an overly bold statement--that the
possibility of creating a SOAP interface demonstrates the value of an
abstract model.  Simply naming a variety of possible protocol substrates
doesn't really put that question to rest, if anyone is raising it.

8 says the model makes some assumptions about how keys will be handled
by an admin interface.  This wording is confusing to me.  First, the
model doesn't appear to make any such assumptions; they sound more like
ancillary aspects which the author considers a good idea.  Second, if
the keys are being modified only by the change-password protocol, how
are they also being modified "(using the administrative interface)"?
And third, if the keys are write-only but only modified via the
change-password protocol, what's the point of discussing them in the
model?

Editorial comments (the author is welcome to disagree with some of these
and ignore them):

* The writing style makes very sparing use of commas.  I don't want to
go over every case where I would have used a comma, but there were a
bunch of them.

* eg or e.g should be written as "e.g." consistently.  Similarly, ie or
i.e should be written as "i.e." consistently.

* "single valued" should be "single-valued".  "multivalued" or "multi
valued" should be "multi-valued".

* In 2, "administrate" should be "administer".

* In 2, "... MUST NOT be taken to imply any particular modeling paradigm
so that neither an object oriented model or an LDAP schema is intended"
incorrectly associates the "so that neither..." clause with what is
being prohibited.  I recommend a different sentence structure.  Also,
it's neither...nor, not neither...or.

* In 3, strike "Note that".

* In 6.1.1.1, "implmementation" -> "implementation".

* In 6.1.1.4, strike either the parentheses around "temporarily" or
strike it entirely.  Parentheticals should not modify the meaning of the
sentence.

* In 6.1.1.11, "maximum ticket lifetime for tickets" -> "maximum
lifetime for tickets".

* In 6.1.1.13, "enctype7" -> "enctype".

* In 6.1.1.13, add Harvard comma to "server, client and session keys".

* In 6.1.2 and 6.2.3, the parentheticals clarifying what
"implementation" could mean seem redundant.  Either classifying a
standards document arising from the model as an "implementation" is
confusing and wrong, or it should be explained once (as it is in section
3) and the reader should be expected to understand that henceforth.

* In 6.2, "completenes" -> "completeness".

* In 6.4.2.3, i.e appears used when e.g. is meant, since a keying policy
could apply to password changes as well as principal creation.

* In 6.4.2.3, the wrong form of "determine" is used.  The whole sentence
is awkward; striking "possibly many" would help a little bit.

* In 7.1, the word "backending" is coined.  "Back-ending" might be
slightly less abusive of the English language, although either is pretty
informal.

* In 7.1, Harvard comma in "principals, policy and other".

* In 7.2, "access-protocol" -> "access protocol".

* In 7.3, "SOAP-interface" -> "SOAP interface".

* 7.4 contians a run-on sentence which is also missing period.

* Section 8 contains a parenthentical signed by leifj which should go
before publishing.

* In 8, "access control objects is" -> "access control objects are".

* In 8, "etc. etc." is excessively informal.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 09 Mar 2010 23:12:28 +0100

> Semantic comments:

First of all: thank you for your in-depth review and detailed comments!

> canonical principal name for salting.

I am almost sure we've discussed this but I can't find the reference
to the thread in the list archive right now. Can somebody help?

> multiple realms, do they necessarily have the same name in each realm?

These two might be left-overs from an earlier version where realm didn't
exist. After a discussion on the list realms were back in the model but
I may have missed some minor consequences of that. I'll review and 
clarify the language.

Greg raises a question that I'd like more comments on:

Is it reasonable for a principal to be a member of several realms or
should that just be two principals?

> containing only a DES3 key.

It should be read as "If a server supports an enctype _for a principal_ 
then that enctype must be present in at least one key for the principal 
in question." In other words: if its there then it is allowed. Almost
a tautology, I agree but this was the result of a discussion before the
last IETF about how to signal support for an enctype.

> multiple KeySets associated with a principal (key rollover situations).

Sure...

> objects are retrieved in blobs?

This is largely historic now and possibly redundant. The origins of the
information model is a number of early attempts to build LDAP schema
for a KDC, many of which would happily let you play with keys as LDAP
attributes.

Do you have a suggestion here - remove the remark or clarify?

> model implementation (a standard document).

Not intentionally. Are you referring to the use of RFC2119 terms in 6.3? 
In that case there is a note on their interpretation at the beginning of 
the text...

> 6.4.1.4 does not define what the "applicability of a policy" means.

Good point. I had to think twice before remembering it. I am pretty sure
this is supposed to mean things like "keying policy" or "credential 
change policy".

> doesn't really put that question to rest, if anyone is raising it.

Speaking as someone who has from time to time been called upon to
deploy multiple interfaces to the same underlying system without the 
benefit of an information model I disagree that the statement is bold.

> change-password protocol, what's the point of discussing them in the

The point of discussing keys in this ways is largely historic (see my
note above about the origins of the model). I decided to put these words
into the security considerations because I didn't want anyone to read
the model and jump to the conclusion that changing keys using (say) a
NetConf interface would be as good as using the set-change-password 
protocol. In fact I think it would be a very bad idea and I wanted the
standard to reflect that view. Feel free to disagree!

> Editorial comments (the author is welcome to disagree with some of these

 From this point on I'm perfectly happy to accept your authority and
command of the language of the Bard ;-)

---

From: Luke Howard <[email-masked]>
Date: Wed, 10 Mar 2010 00:07:09 +0100

> should that just be two principals?

Surely the latter, otherwise are you not circumventing the cross-realm model?

-- Luke

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 9 Mar 2010 17:50:49 -0800

> Surely the latter, otherwise are you not circumventing the cross-realm model?

I hadn't thought of it in just those terms, but I agree (that they're just two principals).  I can't think of any convincing counterexamples.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: "Douglas E. Engert" <[email-masked]>
Date: Wed, 10 Mar 2010 10:16:15 -0600

> Surely the latter, otherwise are you not circumventing the cross-realm model?

I say the latter too.

A KDC only issues tickets for principals its own realm.

The KDC will accept a krbtgt ticket issued by a cross realm
if it has the access to the key. I have always looked at the storing
of the cross-realm principals in the database as a short cut to not
having to store them in a separate keytab.

-- 

  Douglas E. Engert  <[email-masked]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 17 Mar 2010 11:02:48 -0400

I finally got around to reading the draft by Leif. I think its heading in the right direction, as KDC-management is one of the items needing improvement.

My question is high level: has there been any thought of using (re-using) the work of the DMTF (Distributed Management Task Force) in the area of management. 
http://www.dmtf.org/standards/wsman/

The DMTF people use the CIM language/syntax for modeling (which is similar to what Leif has done in his draft). They then use SOAP and the Web Services stack to build the WS-Management interface.

btw.  WS-Manage is now supported by the majority of vendors in the manageability and instrumentation space.

/thomas/

> -----Original Message-----
> From: [email-masked] [mailto:ietf-krb-wg-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Sunday, March 07, 2010 6:00 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Ietf-krb-wg] I-D Action:draft-ietf-krb-wg-kdc-model-07.txt
> 
> 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.
> 
> implementation to automatically retrieve the ASCII version of the Internet-
> Draft.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 22 Mar 2010 19:23:38 +0100

> btw.  WS-Manage is now supported by the majority of vendors in the manageability and instrumentation space.

My ambition was always to stay away from any one metamodel since you can
never get people to agree on those. Today If I'd have to choose a meta-
model for the internet then probably yang is as good a candidate as any

If the community wants WS-M*** then it should (as you say) be easy to
write that up as a schema document based on the information model.

	Cheers Leif