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

>>>>> "Nico" == Nico Williams <nico@cryptonector.com> writes:

    Nico> On Fri, Sep 14, 2012 at 11:15 AM, Sam Hartman <hartmans-ietf@mit.edu> wrote:
    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.

    Nico> Actually, AD does support varying levels of trust within
    Nico> forests.  An AD client could search the AD configuration
    Nico> partition to decide whether some realm is trusted or not, but
    Nico> this is hard work.

Sorry, clients accept the referral if they can get their own host ticket
and verify it.
That's easy for a client to do and approximates what I said above
assuming their exists a trust from the user's realm to the host's realm.

My comment about AD not having as flexible a trust model as everything
supported by Kerberos involves more comments about GCs etc than that AD
doesn't do a good job for real-world situations of supporting multiple
trust levels.
    >> The intent of that paragraph if is that if you're going outside
    >> of an AD-style trust model you may need to prompt.

    Nico> Then it seems like we need an RFC2119 SHOULD.

We're debating whether the SHOULD can be implemented.

As stated, you should check policy.  I personally think you eventually
get to a point where you have to check by asking the user, but I
certainly don't want to SHOULD that specific way of checking.  If you
find something environment-specific that works better, that's great.
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg