Subject: Re: [Ietf-krb-wg] AD review of draft-ietf-krb-wg-kdc-model

From: Leif Johansson <[email-masked]>
Date: Sun, 13 Nov 2011 03:52:06 +0100

On 08/12/2011 05:12 PM, Stephen Farrell wrote:
> 
> Hi,
> 
> I ended up generating a lot of nitty comments with a just a few 
> slightly more substantive ones. Apologies if this repeats
> something from the various WGLC threads - I didn't see any such
> repeats but the threads happened at various times so I may have
> missed something.
> 
> I've put this into AD evaluation:revised ID needed since I guess at
> least some of these will result in changes and a re-spin. (But 
> people should push back on me if you think I'm wrong there.)
> 
> Cheers, S.

OK so I should have gotten to this much sooner .... however since
there have been no comments from the list I assume nobody has strong
feelings about this so I'll just offer my comments as editor.

Most of the issues are relatively obvious.

I will (unless I hear opposition) issue a new version with fixes for
the obvious stuff and then try to get discussions going for the cases
where we need discussions on the list.

Silence counts as approval.

> 
> These are just in reading order.
> 
> 0) Intro: are the "names used" case sensitive? E.g. if an 
> implementation has a "pRinCIpalName" is that the same as 
> "principalName"? If they're case sensitive then you probably need
> to check that you're consistent within the document (e.g. both 
> "principal" and "Principal" are used).  If case-insensitive then
> you probably need to say that.

Consistency is good but remember that the information model is
a requirements-document for schema-like specifications and those
are in principle free to follow their own case conventions. That
should be made explicit.

> 
> 1) I don't get the last para of section 2 - I think you want to
> say that MUST etc. means MTI but not mandatory to use except where 
> stated. For the MAY etc. you seem to be saying that this means 
> optional to implement except where stated. If that's right then I 
> think some rewording like that should make it clearer. If that's
> not right then some rewording is definitely needed:-) I also see
> that you use SHOULD in 4.1.1.1 but don't say here that its the same
> as RECOMMENDED - are they the same in this interpretation of 2119?
> 
> 2) 4.1.1.1 - add a reference to where to find the definition of
> the "string representation of the principal name" (presumably
> somewhere in 4120?)

sounds good.

> 
> 3) What's an enterprise name? (reference needed)
> 

good catch.

> 4) why is exactly one "salting" principalName correct? Explaining 
> would be good.
> 

this needs discussion on the list I think, especially with comments
from implementors.

> 5) 4.1.1.2  - "may not" - is that "MAY NOT"? Add a reference to
> the "standard ISO date format" (maybe RFC 3339?) Same comment
> applies elsewhere (e.g. 4.1.1.3)
> 

I think it should be a MUST NOT actually. Date format is probably
safe and good to nail down.

> 6) 4.1.1.4 - this requires that the schema language supports
> default values - I think that's ok but is it maybe worth calling
> out in the intro?

I don't parse that. 4.1.1.4 is principalIsDisabled - why does that
need languages?

> 
> 7) 4.1.1.5 - is this counting forever? Be good to say why you
> chose that rather than a count in the last interval for a
> configured interval. (I'm not asking that you change, but just that
> you explain.)

I don't think that was extensively discussed. Do people on the list
care either way?

> 
> 8) 4.1.1.6 - why don't you say the date needs to be equivalent
> here as you did in 4.1.1.2? Maybe just say once how you want
> date/time to be handled.

good catch.

> 
> 9) 4.1.1.10 s/modified/last modified/

yep

> 
> 10) 4.1.1.11 - why say "delta time"? (same elsewhere) just "time
> in seconds" is ok
> 

agree

> 11) 4.1.2 - can a single KeySet or Policy be associated with more 
> than one principal (and should "Principal" be capitalised 
> throughout?)

This needs discussion and comments from implementors.

> 
> 12) 4.2 refers to a set-passwd draft from 2008 - do you really
> want to reference that? I realise its informative, but still.  If
> "most" implementations won't use KeySet objects, is it really
> worth including here?

How about this:

"It is expected that most Kerberos implementations will use
an special-purpose interface for setting and changing Principal
passwords and keys."

> 
> 13) 4.2 - you say that "that enctype must be present" - what about 
> during object creation? Seems like you need to relax that a bit? 
> (And s/must/MUST/?)

No I don't agree. This sais that you must not (I can reformulate
in this way if it helps) have key objects without enctype. This
just sais that key object creation and key generation is atomic.

> 
> 14) 4.2.1.1 - why not just use kvno? and isn't kvno==0 common? If 
> so, then "positive integer" isn't right.

good catch.

> 
> 15) 4.2.2 - s/Keys/Key objects/ and what'd it mean to have one 
> KeySet.kvno and multiple KeySet.Key objects? I don't get that.

It needs to say that there is at most one Key in a KeySet of
any given enctype. Does that help make it clear?

> 
> 16) 4.2.3 - this could be confused as saying that KeySet has an 
> attribute (or Association-like thing) called "Remarks." I suggest 
> changing the style of the heading. (Same for 4.3.3)

Ah ok. I hadn't thought about that. You're probably right. I'll
change it to just "Remarks" or possibly move it up to the set of
paragraphs of 4.2

> 
> 17) 4.3.1.1 - including an example of an enctype string from the 
> IANA registry would help here I think.

yep

> 
> 18) 4.3.1.2 - hmmm - I can see trickiness here - presumably the 
> keyValue octets depend both on the enctype and on the
> implementation (e.g. perhaps endian-ness or some other crypto API
> encoding or handle stuff happens that's implementation specific).
> Maybe you just need to say that these values are unlikely to be
> portable between implementations and maybe shouldn't be exported
> naively in any case, but I'm not sure.  (Same applies to
> keySaltValue I guess but with less liklihood of actual problems
> arising.) This one may need some thought, or else I'm just
> confused.
> 

I don't think you're confused but also I think that is true for
many parts of the model that you can't just pick arbitrary parts
of it and hope it make sense independent of other parts. Do you
think it needs extra clarification in this particular case?

> 19) 4.3.1.4 - I think this needs a reference as the opacity here
> is almost complete:-)

This is about AES keys I think. Maybe just say that "certain string
to key algorithms need extra parameters".

> 
> 20) 4.4.1.1 - how could a policy id be "globally unique" but not
> be "unique within the local admin context"? Something is wrong in
> that sentence.

heh yes indeed. I think this is an old typo. I suggest dropping the
"local" part.

> 
> 21) 4.4.1.2 - this is the 1st time you've said that policies only 
> refer to Key objects (or is it KeySet objects?) Earlier, I thought 
> they were more general. If they are more general, then what does 
> this bit mean when a policy does not refer to a key?
> 

It should be Key - it is policy for selecting the right enctype
basically. Maybe this should get some discussion on the list...

> 22) 4.4.1.4 - I think an example would help here, its not clear to 
> me what'd go here.

I agree.

> 
> 23) I don't get how 4.4 is a "SHOULD implement" but 4.4.2 is MTI? 
> Should it say that 4.4.2 stuff is MTI if you do implement policy
> at all?

Yes!

> 
> 24) I don't get the MTI policy stuff - why is it important that 
> different KDCs have e.g. a password quality policy and use the
> same OID for that? I'm also not clear what'd be likely to go into
> the opaque blob for those policies.

Because if you connect to your new KDC with your usual kadmin client
your UI must be able to explain all the options to you!

	Cheers Leif
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Sun, 13 Nov 2011 18:44:41 -0500

On 11/12/2011 09:52 PM, Leif Johansson wrote:
>> 4) why is exactly one "salting" principalName correct?
>> Explaining would be good.
> 
> this needs discussion on the list I think, especially with
> comments from implementors.

The RFC 3961 string-to-key function requires a salt and possibly
additional parameters.  RFC 4120 defines a default salt which is a
function of the principal name (section 4, paragraph 4).  If a
principal entry has multiple names and no explicit non-default salt,
then only one of those names can be the name used to compute the
default salt.

> This needs discussion and comments from implementors.

In MIT krb5, policies are named global objects intended to be
associated with multiple principals.

I don't know of a use case for a keyset being associated with multiple
principals, since a principal can already have multiple names.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Mon, 14 Nov 2011 04:30:32 -0500

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    Leif> I will (unless I hear opposition) issue a new version with
    Leif> fixes for the obvious stuff and then try to get discussions
    Leif> going for the cases where we need discussions on the list.

Please unless there are objections.

    Leif> Silence counts as approval.

I'll explain a few areas where I don't think silence can count as
approval.

    >> say that MUST etc. means MTI but not mandatory to use except
    >> where stated. For the MAY etc. you seem to be saying that this
    >> means optional to implement except where stated. If that's right
    >> then I think some rewording like that should make it clearer. If
    >> that's not right then some rewording is definitely needed:-) I
    >> also see that you use SHOULD in 4.1.1.1 but don't say here that
    >> its the same as RECOMMENDED - are they the same in this
    >> interpretation of 2119?
    >> 

I didn't see a response to this.
Given how much pain we went through with the current text any adjustment
here requires positive support from the WG.

    >> the "string representation of the principal name" (presumably

    Leif> sounds good.

RFC 1964

    >> configured interval. (I'm not asking that you change, but just
    >> that you explain.)

    Leif> I don't think that was extensively discussed. Do people on the
    Leif> list care either way?

Here discussion is required; silence is insufficient unless someone can
point to previous discussion.

    >> "most" implementations won't use KeySet objects, is it really

    Leif> How about this:

    Leif> "It is expected that most Kerberos implementations will use an
    Leif> special-purpose interface for setting and changing Principal
    Leif> passwords and keys."

For Stephen's benefit, I think the 2008 draft is the direction we'll
ever take if we want to standardize that function.  The draft is kind of
dead because so far no one indicates interest in implementing.

    >> KeySet.kvno and multiple KeySet.Key objects? I don't get that.

    Leif> It needs to say that there is at most one Key in a KeySet of
    Leif> any given enctype. Does that help make it clear?

    >> arising.) This one may need some thought, or else I'm just

Actually, the wire format for Kerberos keys is fairly well standardized.

    >> 19) 4.3.1.4 - I think this needs a reference as the opacity here

    Leif> This is about AES keys I think. Maybe just say that "certain
    Leif> string to key algorithms need extra parameters".

No, please just add a reference to the string_to_key operation in RFC
3961; it takes something called string to key parameters.
You feed the value from 4.3.1.4 into that.
The interpretation of what the opaque value means is enctype dependent.
For AES it is an iteration count.
For DES, it's secretly information about whether to use the old AFS
string2key algorithm.

    >> refer to Key objects (or is it KeySet objects?) Earlier, I
    >> thought they were more general. If they are more general, then
    >> what does this bit mean when a policy does not refer to a key?
    >> 

Leif> It should be Key - it is policy for selecting the right enctype
    Leif> basically. Maybe this should get some discussion on the
    Leif> list...

Hmm.  My interpretation is that policies are more general and this
should be principal.

    >> the opaque blob for those policies.

    Leif> Because if you connect to your new KDC with your usual kadmin
    Leif> client your UI must be able to explain all the options to you!

Can you help me understand how the current text gets you that?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Mon, 14 Nov 2011 10:36:00 +0100

> I'll explain a few areas where I don't think silence can count as 

I agee with those.

> 
> 
> 
>>> 
>>> These are just in reading order. 1) I don't get the last para
>>> of section 2 - I think you want to say that MUST etc. means MTI
>>> but not mandatory to use except where stated. For the MAY etc.
>>> you seem to be saying that this means optional to implement
>>> except where stated. If that's right then I think some
>>> rewording like that should make it clearer. If that's not right
>>> then some rewording is definitely needed:-) I also see that you
>>> use SHOULD in 4.1.1.1 but don't say here that its the same as
>>> RECOMMENDED - are they the same in this interpretation of
>>> 2119?
>>> 
> 
> I didn't see a response to this. Given how much pain we went
> through with the current text any adjustment here requires positive
> support from the WG.
> 
> 
>>> 2) 4.1.1.1 - add a reference to where to find the definition
>>> of the "string representation of the principal name"
>>> (presumably somewhere in 4120?)
> 
> Leif> sounds good.
> 
> RFC 1964
> 
>>> 
> Leif> I don't think that was extensively discussed. Do people on
> the Leif> list care either way?
> 
> Here discussion is required; silence is insufficient unless someone
> can point to previous discussion.
> 
>>> 
>>> want to reference that? I realise its informative, but still.
>>> If "most" implementations won't use KeySet objects, is it
>>> really worth including here?
> 
> Leif> How about this:
> 
> Leif> "It is expected that most Kerberos implementations will use
> an Leif> special-purpose interface for setting and changing
> Principal Leif> passwords and keys."
> 
> For Stephen's benefit, I think the 2008 draft is the direction
> we'll ever take if we want to standardize that function.  The draft
> is kind of dead because so far no one indicates interest in
> implementing.
> 
> 
> 
>>> 
>>> 18) 4.3.1.2 - hmmm - I can see trickiness here - presumably
>>> the keyValue octets depend both on the enctype and on the 
>>> implementation (e.g. perhaps endian-ness or some other crypto
>>> API encoding or handle stuff happens that's implementation
>>> specific). Maybe you just need to say that these values are
>>> unlikely to be portable between implementations and maybe
>>> shouldn't be exported naively in any case, but I'm not sure.
>>> (Same applies to keySaltValue I guess but with less liklihood
>>> of actual problems arising.) This one may need some thought, or
>>> else I'm just confused.
>>> 
> 
>>> 19) 4.3.1.4 - I think this needs a reference as the opacity
>>> here is almost complete:-)
> 
> No, please just add a reference to the string_to_key operation in
> RFC 3961; it takes something called string to key parameters. You
> feed the value from 4.3.1.4 into that. The interpretation of what
> the opaque value means is enctype dependent. For AES it is an
> iteration count. For DES, it's secretly information about whether
> to use the old AFS string2key algorithm.
> 
>>> 21) 4.4.1.2 - this is the 1st time you've said that policies
>>> only refer to Key objects (or is it KeySet objects?) Earlier,
>>> I thought they were more general. If they are more general,
>>> then what does this bit mean when a policy does not refer to a
>>> key?
>>> 
> 
> 
> Leif> It should be Key - it is policy for selecting the right
> enctype Leif> basically. Maybe this should get some discussion on
> the Leif> list...
> 

I don't parse that. Lets do this one at the mic.

> 
>>> 24) I don't get the MTI policy stuff - why is it important
>>> that different KDCs have e.g. a password quality policy and use
>>> the same OID for that? I'm also not clear what'd be likely to
>>> go into the opaque blob for those policies.
> 
> Leif> Because if you connect to your new KDC with your usual
> kadmin Leif> client your UI must be able to explain all the options
> to you!
> 

I'm not sure I'd argue that the text is perfect, just that this is what
it is for.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Tue, 15 Nov 2011 06:54:16 +0100

> through with the current text any adjustment here requires positive

I suggest the following arguably simpler formulation:

The terms MUST, REQUIRED  mean mandatory to implement (MTI), ie that
the schema implementing this model MUST provide said feature. Such a
feature MAY in general be OPTIONAL to use. If a feature must be
implemented and MUST NOT be OPTIONAL to use this is made explicit in
this document. The term MAY, OPTIONAL and RECOMMENDED means that an
implementation MAY  REQUIRE the feature due to the particular nature
of the schema/modelling language. In some cases this is expressly
forbidden by this model (feature X MUST NOT be REQUIRED by an
implementation).

>>> (presumably somewhere in 4120?)
thx

> can point to previous discussion.

yes

> Hmm.  My interpretation is that policies are more general and this 

yeah you are right.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 15 Nov 2011 07:14:53 +0100

Some more things I came upon...

>> 3) What's an enterprise name? (reference needed)

Actually I think enterprise names are part of the referrals draft
(right?) and we may not want to ride on a normaitve reference to
that one.

I suggest I remove the references to enterprise names and just
talk about 'aliases' which is generic enough for this model I think.

<snip>

> I don't parse that. 4.1.1.4 is principalIsDisabled - why does that 

Ah now I get it. Doh.

	Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Tue, 15 Nov 2011 03:24:34 -0500

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    Leif> Some more things I came upon...

    >>> 3) What's an enterprise name? (reference needed)

    Leif> Actually I think enterprise names are part of the referrals
    Leif> draft (right?) and we may not want to ride on a normaitve
    Leif> reference to that one.

Speaking as an individual I expect to ask the chairs to last call
referrals this week.  So, it's not as bad as it could be.

Enterprise names are more special than normal aliases.  However, I can
understand if you want to remove the references.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Tue, 15 Nov 2011 04:47:19 -0500

I don't understand this at all.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Tue, 15 Nov 2011 11:04:23 +0100

On 11/15/2011 10:47 AM, Sam Hartman wrote:
> The terms MUST, REQUIRED  mean mandatory to implement (MTI), ie
> that the schema implementing this model MUST provide said feature.
> Such a feature MAY in general be OPTIONAL to use. If a feature must
> be implemented and MUST NOT be OPTIONAL to use this is made
> explicit in this document. The term MAY, OPTIONAL and RECOMMENDED
> means that an implementation MAY  REQUIRE the feature due to the
> particular nature of the schema/modelling language. In some cases
> this is expressly forbidden by this model (feature X MUST NOT be
> REQUIRED by an implementation).
> 
> 
> 

OK I suggest we get this cleared up in the room this week.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 Nov 2011 16:08:20 -0500

> > "most" implementations won't use KeySet objects, is it really

Actually, yes.  That document is a current work item in our charter, and
while it may be a while before it gets finished, we haven't abandoned
it, and I think an informative reference is appropriate.  Note that in
the absence of that protocol, the best option available today is a
combination of a predecessor password-change protocol and
implementation-specific administrative interfaces.

The important point is that in practice, most implementations will
handle key management specially.  Thus, an administrative service might
not include KeySets in its schema, even though they are part of the
overall KDC data model.

In the interest of capturing a complete model of the data a KDC needs, I
think including them here is appropriate.

> an special-purpose interface for setting and changing Principal

Sounds fine to me.  I also wouldn't object to adding "..., such as the
set/change password protocol [I-D...]"

> any given enctype. Does that help make it clear?

Right; a KeySet is a collection of keys of different enctypes; the kvno
applies collectively to the set, not to individual keys.  This is
consistent with the versioning model actually used by KDCs which support
multiple kvnos.

> > encoding or handle stuff happens that's implementation specific).

No; this is enctype-specific but not implementation-specific.  These are
"protocol keys" in the RFC3961 sense, just as Kerberos session keys are,
and their wire format is an attribute of the enctype and a required part
of the enctype profile as described in RFC3961 section 3.

> to key algorithms need extra parameters".

No.  The string-to-key operation, which is also part of the RFC3961
enctype profile, takes a single octet-string parameter whose format is
specific to each enctype and opaque to most of the protocol, including
any admin protocol based on the data model defined by the present
document.  Again, the format of the value is enctype-specific but is
part of the enctype profile and thus not implementation-dependent.

Note that both the keySaltValue and keyStringToKeyParameter fields
should be optional, in the sense that they may not be set explicitly for
every key, and the protocol specifies default behavior when they are not
set (for the salt, this is defined by the Kerberos protocol; for the s2k
parameters, it is an attribute of the enctype profile).

> basically. Maybe this should get some discussion on the list...

I think this was maybe a leftover.  The current document associates
Policies with Principals; there is no provision for policies specific to
a particular Key or KeySet.

In any case, the language on this field should not refer specifically to
keys; it's general.  If this bit is true, the policy is critical, and if
you don't know what it means, you cannot do anything with the object to
which it is attached.

I'd have to go back through past list discussion to determine whether
we've ever talked about whether to permit attaching policies to keys or
keysets, rather than entire principals.

> your UI must be able to explain all the options to you!

Personally, I think the format of keying and ticket flag policies ought
to be nailed down (in a schema document, not here).  However, that's not
likely to be possible for password quality and management policies,
which are likely to have representations specific to each Kerberos
implementation.

I don't recall whether we had a discussion about using fixed identifiers
for policies that are likely to have implementation-dependent
representation.  The more I think about this, the more I think we want
to _not_ do that, because doing so makes it more difficult to write a
kadmin client which actually understands the format for a particular
implementation, and likely makes life annoying when trying to move data
from one KDC implementation to another.  The benefit Simon refers to can
be gained by ensuring the admin protocol includes a way to discover a
descriptive name for each policy, whether or not it is one of the MTI
ones.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 Nov 2011 16:22:34 -0500

On Tue, 2011-11-15 at 04:47 -0500, Sam Hartman wrote:
> I don't understand this at 

The problem here is that we are trying to use one set of requirements
keywords to describe two layers of requirements.

At the first layer, we are describing what must be part of a schema
derived from this model.  Some features, such as principals, are
REQUIRED and so must be part of any schema.  Others, such as KeySets,
are OPTIONAL, and may be omitted from the schema entirely.

At the second layer, we are also placing constraints on what
requirements a schema can impose on implementations of that schema.  For
example, we say that not only are principals REQUIRED to be part of a
schema, but also that a schema must REQUIRE that they be implemented by
implementations of that schema.

Similarly, KeySets are OPTIONAL and so may be omitted from a schema
entirely, but even a schema which includes them may not REQUIRE that
they be implemented in implementations of that schema.

The majority of requirements language in this document operates at the
first level, specifying what must be part of a schema based on this data
model.  The paragraph above the one we're discussion attempts to explain
that RFC2119 language is to be interpreted in this context, with an
"implementation" being an implementation of the data model; in other
words, an "implementation" is a schema based on this data model.

The paragraph under discussion attempts to further clarify that when we
say something is REQUIRED, we mean that it must be part of every schema,
and not that it must be implemented in every implementation of every
schema.  When we mean the latter, we say it more explicitly, and phrase
it as a requirement upon schemas ("The principal... MUST NOT be
OPTIONAL").

I agree the present text is awkward, but this is an awkward area, and I
don't have any idea how to improve the text.

-- Jeff

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 15:40:13 -0600

>> any given enctype. Does that help make it clear?

Hmmm, both MIT and Heimdal, IIRC, support having more than one key
with the same enctype and kvno.  Yes, the first one wins, but there's
a distinction between a key that has a salt associated with it and one
that doesn't.  I saw code to this effect recently, and could dig it up
if you like.  That said, I have no issue with excluding this from the
mode, as I consider that sort of mess pathological and legacy.

> consistent with the versioning model actually used by KDCs which support

Note that this is not the only way to model this.

Another way to model key sets is to have each key be an object with a
kvno as one field, and then explain that one must group keys by kvno
into keysets.  My point: don't exclude this approach.

> a particular Key or KeySet.

Policies should only associate with principals, even where policies
affect choices of keys/enctypes.

> which are likely to have representations specific to each Kerberos

I think policies need a model just as much as principals.

There are common password policy elements that can be standardized.
We've been over this in the old discussions of the change/set
password/key protocol (Larry wanted specific error codes for all the
password quality policies he cared about, but we knew we needed to be
flexible so we also provided for localized error messages by which to
describe errors not covered by specific error codes).

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Fri, 18 Nov 2011 01:47:17 +0100

On 11/17/2011 10:40 PM, Nico Williams wrote:
>>>> 15) 4.2.2 - s/Keys/Key objects/ and what'd it mean to have
>>>> one KeySet.kvno and multiple KeySet.Key objects? I don't get
>>>> that.
>>> 
> with the same enctype and kvno.  Yes, the first one wins, but
> there's a distinction between a key that has a salt associated with
> it and one that doesn't.  I saw code to this effect recently, and
> could dig it up if you like.  That said, I have no issue with
> excluding this from the mode, as I consider that sort of mess
> pathological and legacy.

thank you!

> 
>> Right; a KeySet is a collection of keys of different enctypes;
>> the kvno applies collectively to the set, not to individual keys.
>> This is consistent with the versioning model actually used by
>> KDCs which support multiple kvnos.
> 
> Another way to model key sets is to have each key be an object with
> a kvno as one field, and then explain that one must group keys by
> kvno into keysets.  My point: don't exclude this approach.
> 

imo that is just a representation of KeySet...

	Cheers Leif

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 22:50:18 -0600

On Fri, Aug 12, 2011 at 10:12 AM, Stephen Farrell
<[email-masked]> wrote:
> 6) 4.1.1.4 - this requires that the schema language supports default
> values - I think that's ok but is it maybe worth calling out in the
> intro?

I think that's fine.  Any IDL that allows for optional fields
effectively allows for default values by convention.  Even without
optional fields one could still use conventions by which to encode
presence/absence and default values.  LDAP, SQL, XML, JSON, XDR, ...
all can handle this :)

OK, I got nitty, please excuse me.

Nico

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 23:01:51 -0600

On Thu, Nov 17, 2011 at 6:47 PM, Leif Johansson <[email-masked]> wrote:
>> On Thu, Nov 17, 2011 at 3:08 PM, Jeffrey Hutzelman <[email-masked]>

Yes, and the better one for a SQL schema, IMO.

Another representation is to serialize a set of keys where each key
has kvno and enctype.

I mention this because I think there's really only one class that has
to be mandated for any KDB schema: the Principal class.  Policies are
nice, and if an implementation has them, those too should a
first-class class.  But KeySets?  I object to any requirement that
KeySets be required to be a first-class class.

Nico

---

From: Leif Johansson <[email-masked]>
Date: Fri, 18 Nov 2011 06:19:21 +0100

> I mention this because I think there's really only one class that
> has to be mandated for any KDB schema: the Principal class.
> Policies are nice, and if an implementation has them, those too
> should a first-class class.  But KeySets?  I object to any
> requirement that KeySets be required to be a first-class class.

OK then I misunderstood you.

You are actually arguing for going in and re-factoring the model.

I sorta hoped we were beyond that level of change to the model.

	Cheers Leif

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 23:20:47 -0600

> I sorta hoped we were beyond that level of change to the model.

No, I'm asking that you don't exclude a reasonable mapping to a schema.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Fri, 18 Nov 2011 06:21:48 +0100

On 11/18/2011 06:20 AM, Nico Williams wrote:
>>> I mention this because I think there's really only one class
>>> that has to be mandated for any KDB schema: the Principal
>>> class. Policies are nice, and if an implementation has them,
>>> those too should a first-class class.  But KeySets?  I object
>>> to any requirement that KeySets be required to be a first-class
>>> class.
>> 

Ah (phew). Do you think the current text does that? If so can you
propose changes to resolve that?

	Cheers Leif

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 23:40:08 -0600

>> I suggest the following arguably simpler formulation:

I don't find it simpler, but maybe only because I have not yet
explored alternatives.

> keywords to describe two layers of requirements.

+1.

A trivial solution would be to say that anything that's required of
schemas in the model is also to be required by the schema, and
anything optional for the schemas should be optional in the schemas.
Then there would be no need for either new terminology nor odd
phrasing.  A touch too trivial a solution, sadly.

Thus we'll either need new terminology, or careful [but probably
necessarily odd] phrasing.  Or, alternatively, separation of
requirements.  One section (paragraph, list element, whatever)
describes layer 1 requirements for a given element of the model, while
another describes layer2 requirements for derived schemas.  But I've
not read this I-D in a long time.  I'll read it soon.

> they be implemented in implementations of that schema.

Right.

A schema that chooses to represent KeySets by a first-class mechanism
(table, class, ...) MUST require that keys be stored using that
mechanism (as rows, instances, ...).  How could it be otherwise?

However, it may be OPTIONAL to have instances of KeySets (a key-less
principal is not worthless, even one with no keys, no password, and no
PKINIT public keys/certs/Name+TA may not be entirely worthless).  So,
REQUIREing a representation of KeySets cannot require that a derived
schema REQUIRE instances of KeySets.  Thus my proposed trivial
solution is too trivial.

Nico

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 23:55:27 -0600

> propose changes to resolve that?

Yes.  I just read that section of the I-D (section 4.2).

Here's my proposed new text:

   In Kerberos principals are associated with zero or more symmetric
   secret keys, and each key has a key version number (kvno) and
   enctype.  In this model we group keys by kvno into instances of
   KeySet.  A Principal can have zero or more instances of KeySet,
   each of which MUST have one or more keys.  Each KeySet is
   associated with exactly one principal.

   Schemas derived from this model MAY lack a direct analogue
   of this model's KeySet.

Note how in the first paragraph the RFC2119 terms are used to refer to
what is expected of actual instances of whatever derivative schema we
have.  While in the second paragraph we use RFC2119 terms to refer to
requirements of the schema.

I used terminology not in the I-D though.  I think we'll want to speak
of classes and instances, or classes and objects, or whatever we
choose, and to be consistent about that.  So feel free to edit the
above to be consistent with the rest of the I-D.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 18 Nov 2011 02:02:31 -0500

> mechanism (as rows, instances, ...).  How could it be otherwise?

No.  A schema that chooses such a representation MUST NOT require that
implementations implement that part of the schema at all.  A Kerberos
implementation may choose to store and manage its keys in a completely
different way, and not expose them via a kadmin interface based on this
data model.

-- Jeff

---

From: Nico Williams <[email-masked]>
Date: Fri, 18 Nov 2011 10:25:43 -0600

> different way, and not expose them via a kadmin interface based on this

Oh, that.  I wouldn't make that a requirement.  Informative text
should suffice for that.

Nico

---

From: Leif Johansson <[email-masked]>
Date: Sun, 20 Nov 2011 21:23:00 +0100

On 11/18/2011 06:55 AM, Nico Williams wrote:
> Schemas derived from this model MAY lack a direct analogue of this 
> model's KeySet.
> 
> Note how in the first paragraph the RFC2119 terms are used to
> refer to what is expected of actual instances of whatever
> derivative schema we have.  While in the second paragraph we use
> RFC2119 terms to refer to requirements of the schema.
> 
> I used terminology not in the I-D though.  I think we'll want to 
> speak of classes and instances, or classes and objects, or
> whatever we choose, and to be consistent about that.  So feel free
> to edit the above to be consistent with the rest of the I-D.
> 

right I will try to massage the above. I think it a good compromise.

	Cheers Leif