Subject: transited realm description in 2.7

From: Ken Raeburn <[email-masked]>
Date: Tue, 13 Aug 2002 18:05:15 -0400

After talking a bit with Matt Hur and others, I believe the
description of the transited realm checking needs a little
clarification.  The method of verification may be obvious to someone
who already understands the model used, but it isn't to someone who
doesn't.

This change doesn't describe the model in detail -- this draft
shouldn't become a tutorial on general security issues -- but I hope
gives enough info to point them in the right direction, for
implementation and maybe conceptually as well.

The last third or so of the first paragraph is new; the rest was in
the 02/21/02 version on Cliff's web page, as one paragraph.  (Well, I
also changed the possessive "KDC's" to the plural "KDCs".)

Comments?  Matt, does this clarify it enough?

    <h3>2.7 Transited Policy Checking</H3>

    In Kerberos, the application server is ultimately responsible for
    accepting or rejecting authentication and should check that only
    suitably trusted KDCs are relied upon to authenticate a principal.
    The transited field in the ticket identifies which KDCs were involved
    in the authentication process and an application server would normally
    check this field.  If any of these are untrusted to authenticate the
    indicated client principal (probably determined by a realm-based
    policy), the authentication attempt must be rejected.  The presence of
    trusted KDCs in this list does not provide any guarantee; an untrusted
    KDC may have fabricated the list.

    <P>

    While the end server ultimately decides whether
    authentication is valid, the KDC for the end server's realm may apply
    a realm specific policy for validating the transited field and
    accepting credentials for cross-realm authentication.  When the KDC
    applies such checks and accepts such cross-realm authentication it
    will set the TRANSITED-POLICY-CHECKED flag in the service tickets it
    issues based on the cross-realm TGT.  A client may request that the
    KDCs not check the transited field by setting the
    DISABLE-TRANSITED-CHECK flag.  KDCs are encouraged but not required to
    honor this flag.

---

From: Martin Rex <[email-masked]>
Date: Wed, 14 Aug 2002 17:41:57 +0200 (MET DST)

>     KDC may have fabricated the list.

I know that interrealm trust and transited fields are a longstanding
Kerberos protocol feature, but for Kerberos implementations that
offer GSS-API to application services this simply doesn't apply.

GSS-API-based application servers are ultimately unable to check
transited fields.  This should be mentioned here one might think
about adding implementation guidelines around this feature into
the next rev of the Kerberos 5 gssapi mechanism...

>     DISABLE-TRANSITED-CHECK flag.  KDCs are encouraged but not required to

Having the local realm's KDC verify transited fields (and optionally
apply fancy policies) looks like the only option for (protecting)
GSS-API based services.

-Martin

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 14 Aug 2002 13:59:06 -0400

> offer GSS-API to application services this simply doesn't apply.

Sure it does.  "Application" in this context doesn't mean only the
GSSAPI application code, it includes the GSS krb5 mechanism itself,
and supporting configuration information (e.g., where's your keytab
file stored? where are your credentials stored?).

> apply fancy policies) looks like the only option for (protecting)

Perhaps the configuration information will say that the KDC must have
set the T-P-C flag for cross-realm credentials to be trusted.  Perhaps
not.

Ken