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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 7 Feb 2005 13:17:49 -0800

Current text:

<t>
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 <xref
target="CLAR"/>).
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.</t> 

Do you mean the text should be:

<t>
The AS 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 <xref
target="CLAR"/>).
Furthermore, any TGS MUST copy such authorization data from tickets
used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
and it can wrap or unwrap the data into or out-of the AD-IF-RELEVANT
container, 
depends on if the list of CAs satisfies the local KDC's realm's
policy.</t>

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Monday, February 07, 2005 12:59 PM
To: Liqiang(Larry) Zhu
Cc: Paul Leach; [email-masked]
Subject: Re: Pkinit -23 comment: InitialVerifiedCAs *always* wrapped in
AD-IF-RELEVANT

On Mon, Feb 07, 2005 at 11:33:50AM -0800, Liqiang(Larry) Zhu wrote:
> 
>  Nicolas Williams wrote:
> > It adds to interop testing complexity when we want to go to 
> > Standard,
> 
> Good, we have a reason to remove it. 

That would be reason to remove it _later_.

> > Kerberos V x-realm transit and PKI trust paths are similar concepts,
> 
> 
> I would not let the initial authenticating realm to decide whether 
> this auth-data is critical or not, that is the responsibility of the 
> app server's KDC. but currently the app server's KDC has no way to 
> either move the auth-data into ad-if-relevant container.

I don't see why a TGS can't wrap an AD-INITIAL-VERIFIED-CAS found in the
request's ticket to a AD-IF-RELEVANT in the ticket to be issued if it
(the TGS) decides that the AD-INITIAL-VERIFIED-CAS passes local realm
policy.  Wrapping/unwrapping AD-INITIAL-VERIFIED-CAS is akin to
setting/resetting the transited policy checked flag.

> app server's KDC can check the transited realms for the initial 
> authenticating realm.

A PKINIT AS presumably will not issue tickets to clients whose certs it
could not validate, therefore a PKINIT AS really should wrap
AD-INITIAL-VERIFIED-CAS in a AD-IF-RELEVANT.  But that's about as far as
that goes, because when crossing realms each KDC and/or the target
application have to apply any policy they may have to the realm transit,
including initial CA path.

That's the crux of what we decided at the Boulder interim meeting, that
in so far as PKINIT bridges PKI and Kerberos V it also extends the
notion of trust paths that may be traversed, that we should allow for
validation of the entire path to be consistent with how realm transiting
is handled in Kerberos V.

> It is easier to remove this rather than making it clean, considering 
> we are in such a late stage.

I don't agree.

> If this turns out to be needed in the future, we can always work on a 
> separate ID to make it critical, what do you think?

I'm not sure that we can recover the security properties we have now
with that approach.

Nico
--

---

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

> depends on if the list of CAs satisfies the local KDC's realm's

Yes.

---

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

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[email-masked]> writes:

    Liqiang(Larry)> Do you mean the text should be:

    Liqiang(Larry)> <t> The AS MAY wrap any AD-INITIAL-VERIFIED-CAS
    Liqiang(Larry)> data in AD-IF-RELEVANT containers if the list of
    Liqiang(Larry)> CAs satisfies the KDC's realm's policy (this
    Liqiang(Larry)> corresponds to the TRANSITED-POLICY-CHECKED ticket
    Liqiang(Larry)> flag <xref target="CLAR"/>).  Furthermore, any TGS
    Liqiang(Larry)> MUST copy such authorization data from tickets
    Liqiang(Larry)> used in a PA-TGS-REQ of the TGS-REQ to the
    Liqiang(Larry)> resulting ticket, and it can wrap or unwrap the
    Liqiang(Larry)> data into or out-of the AD-IF-RELEVANT container,
    Liqiang(Larry)> depends on if the list of CAs satisfies the local
    Liqiang(Larry)> KDC's realm's policy.</t>

I believe this proposed text better reflects how we intended the field
to work.