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

>>>>> "Stephen" == Stephen Farrell <[email protected]> writes:

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

What a lot of clients end up doing is confirming that the referred-to
realm is in something like an AD forest.
It would be valuable to mention that as an option  for the local policy.
It's actually not a bad choice in a lot of environments, although
obviously if the trust within a forest varies widely (something that
Kerberos supports but AD doesn't support as much)
then you might need to be more clever.

The intent of that paragraph if is that if you're going outside of  an
AD-style trust model you may need to prompt.

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

I don't think this is explicitly stated.
It's true for AS and TGS.
Will state in the post-lc update.

IN practice the point is kind of moot since every implementation that
seems to be in wide use implements canonicalize. This spec took a while
in the standardization process:-)



    Stephen> nits:

Will deal during post-lc update.
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg