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

From: Stephen Farrell <[email-masked]>
Date: Fri, 12 Aug 2011 16:12:53 +0100

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.

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.

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?)

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

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

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)

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?

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.)

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.

9) 4.1.1.10 s/modified/last modified/

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

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

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?

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/?)

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

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.

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)

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

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:-)

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.

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?

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

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?

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.

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

---

From: Leif Johansson <[email-masked]>
Date: Sat, 13 Aug 2011 14:11:56 +0200

> people should push back on me if you think I'm wrong there.)

Thank you for the review! I just did a quick read-through of these
and they mostly seem like good catches. Some of the more substantiative
may need some thought may turn up some comments/reactions to some of
the points. In any case this needs a new version.

	Cheers Leif