Subject: RE: Pkinit -23 comment: InitialVerifiedCAs *always* wrapped in AD-IF-RELEVANT

From: "Paul Leach" <[email-masked]>
Date: Mon, 7 Feb 2005 10:14:46 -0800

We are talking about this because I can not see what value there is to
having the option for it to be critical or non-critical, whereas it adds
complexity.

If someone could explain what security problem results if the KDC always
sends it and always wraps it in AD-IF-RELEVANT, then I would be
satisfied. (Saying it is the same as the tranisited realm issue doesn't
help me; I don't understand that one either.)

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Monday, February 07, 2005 9:30 AM
To: Paul Leach
Cc: [email-masked]
Subject: Re: Pkinit -23 comment: InitialVerifiedCAs *always* wrapped in
AD-IF-RELEVANT

On Sun, Feb 06, 2005 at 09:19:58PM -0800, Paul Leach wrote:
> Why does it have to be critical?

For the same reason as transited.

That said, the transited field of Ticket is somewhat special in this
regard as its criticality is modified by the TRANSITED-POLICY-CHECKED
flag and, in any case, applications aren't required to treat it as
critical (clarifications says "...SHOULD check the transited field.").

The PKINIT I-D already has appropriate text allowing the KDC to use wrap
AD-INITIAL-VERIFIED-CAS in an AD-IF-RELEVANT ad container in some
circumstances:

   The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
   containers if the list of CAs satisfies the KDC's realm's policy
   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag).
   Furthermore, any TGS must copy such authorization data from tickets
   used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
   including the AD-IF-RELEVANT container, if present.

So, why are we even talking about this?

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 7 Feb 2005 12:29:26 -0600

> having the option for it to be critical or non-critical, whereas it adds

It adds a boolean configuration knob.  It adds to interop testing
complexity when we want to go to Standard, but since most users will set
this knob the same way it needn't add to everyday testing complexity if
you don't want it to.

> help me; I don't understand that one either.)

Application-specific transit policies allow for a relaxed realm-wide
transit policy and tighter transit policies for specific applications.

In most intranets this is a feature noone needs.  But Kerberos V is not
designed only for use on intranets and we may need this feature in the
future (to say nothing of anyone relying on it now, probably in the .edu
world).

Kerberos V x-realm transit and PKI trust paths are similar concepts, at
least from the p.o.v. of applications that have transit policies.

For the configuration-knob-averse a single KDC knob could be used to
control whether the KDC always sets the transited policy checked flag
and whether it wraps AD-INITIAL-VERIFIED- CAS in AD-IF-RELEVANT.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Feb 2005 17:31:30 -0500

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

    Nicolas> On Mon, Feb 07, 2005 at 10:14:46AM -0800, Paul Leach
    Nicolas> wrote:
    >> We are talking about this because I can not see what value
    >> there is to having the option for it to be critical or
    >> non-critical, whereas it adds complexity.

    Nicolas> It adds a boolean configuration knob.  It adds to interop
    Nicolas> testing complexity when we want to go to Standard, but
    Nicolas> since most users will set this knob the same way it
    Nicolas> needn't add to everyday testing complexity if you don't
    Nicolas> want it to.

No.  Your implementation is not required to have the configuration knob.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 7 Feb 2005 16:38:27 -0600

> No.  Your implementation is not required to have the configuration knob.  

Are KDCs allowed to always set the TRANSITED-POLICY-CHECKED flag?  My
reading of clarifications is that, well, it's not clear!  It says when
KDCs may set it, but it doesn't say whether a no-op transit policy is
allowed, or whether transit policies may/should/must be configurable at
the KDC.

Presumably KDCs should not set the TRANSITED-POLICY-CHECKED flag unless
they applied some policy, and presumably implementations should not
hardcode a blanket no-op policy -- such policies ought to be
configurable.  The same ought to apply to AD-INITIAL-VERIFIED-CAS and
AD-IF-RELEVANT wrapping.

Nico
--