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