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

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Sep 2012 01:46:42 +0100

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-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Fri, 14 Sep 2012 12:15:57 -0400

>>>>> "Stephen" == Stephen Farrell <[email-masked]> 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-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Sep 2012 11:43:58 -0500

> then you might need to be more clever.

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

Also, a forest is not / need not be strictly hierarchical, so it can
be really hard for a client to make this check.

> AD-style trust model you may need to prompt.

Then it seems like we need an RFC2119 SHOULD.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Fri, 14 Sep 2012 14:08:03 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> On Fri, Sep 14, 2012 at 11:15 AM, Sam Hartman <[email-masked]> wrote:
    >> 
    >> 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
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Sep 2012 13:48:20 -0500

> Sorry, clients accept the referral if they can get their own host ticket

Sure.  I think we both meant to say different things.  AD can
represent less than full trust between all realms in a forest, but
clients accept referrals to anywhere within the forest.  Clients check
nothing more than the referred-to realm being within the forest -- the
KDC could not have issued the ticket if the referred-to realm did not
trust the client's realm and that's that.  Yes?

> find something environment-specific that works better, that's great.

OK, I see.  Prompting is hard because of the interfaces involved...

Nico

---

From: Sam Hartman <[email-masked]>
Date: Fri, 14 Sep 2012 15:18:39 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> On Fri, Sep 14, 2012 at 1:08 PM, Sam Hartman <[email-masked]> wrote:
    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.

    Nico> Sure.  I think we both meant to say different things.  AD can
    Nico> represent less than full trust between all realms in a forest,
    Nico> but clients accept referrals to anywhere within the forest.
    Nico> Clients check nothing more than the referred-to realm being
    Nico> within the forest -- the KDC could not have issued the ticket
    Nico> if the referred-to realm did not trust the client's realm and
    Nico> that's that.  Yes?

Since a forest can have one-way trusts I think it means more than within
forest.
But I think we're well beyond what's needed for this discussion.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg