AD review of draft-ietf-krb-wg-kerberos-referrals-14

Stephen Farrell <[email protected]> Thu, 13 Sep 2012 01:46:42 +0100
Newsgroups gmane.ietf.krb-wg
Message-ID <[email protected]>

Hi all,

I've done my review of this. Please treat these along with
any other IETF LC comments. I've asked for IETF LC to be
started.

Thanks,
S,

- p10, last para, maybe s/should/ought/ if you don't want
that as a 2119 should? Even without that being a SHOULD, it
seems odd to recommend that the client know about realms, to
the extent that it can differentiate between them, in a spec
whose purpose is to get rid of per-realm configuration from
clients. Is there in fact a missing 2119-level SHOULD here
that also says how to do this with no client config? Or, are
you really assuming that clients won't make any checks, in
which case wouldn't it be better to confess the truth?

- If a KDC receives an AS-REQ with no PA-REQ-ENC-PA-REP or
canonicalize KDC option then I assume that KDC MUST behave
according to 4120. Is that stated explicitly somewhere? Does
there need to be any similar statement about TGS-REQs or TGTs
(since the new padata type is a MAY for TGS-REQs)?

nits:

- more examples would help here, the one in section 8 is
great and more of that would help make this an easier read I
reckon.

- p8, NT-UID could do with a reference or maybe just say
somewhere that "all the name types (NT-*) are defined in RFC
4120"

- p9, Are you saying that all cross-realm uses of
AD-KDC-ISSUED are not "well explored" or just cross-realm
uses of login-aliases? Its not quite clear to which the
SHOULD applies.

- p10, 3rd last para, "used to generate the first referral"
means value used in the first AS-REQ I think? If so, saying
that rather than calling it a referral seems less likely to
mislead. The current text could I guess cause someone to pick
the wrong cname field. Maybe its just me, but I think its odd
to refer to an AS-REQ as a referral. The term referral
suggests a response message to me I guess.

- section 9, s/it including/it includes/?

- p13, "MUST be ignored by the receiving KDC" - I realise
you're talking about the value of the padata type and not the
type, but it reads awfully close to saying that KDCs "MUST
ignore PA-REQ-ENC-PA-REP" whereas you want that a KDC MUST
react to its prescence.

- p13, typo s/The The/The/

- p14, "Because of existing..." that sentence ought not be in
the final RFC so please mark it as such. It'd also be better
to directly ask IANA to do something rather than say "should
be registered." The current text would leave IANA and the RFC
editor wondering about that ought go in the RFC so may as
well fix it now.

- Is "current implementation" still correct in Appendix A?
Just checking in case that's very old text.

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