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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 7 Feb 2005 11:33:50 -0800

Nicolas Williams wrote:
> It adds to interop testing complexity when we want to go to Standard,

Good, we have a reason to remove it. 

> 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.

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

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

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?

The proposed new text:

   The KDC MUST wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
   containers.  Furthermore, any TGS MUST copy such authorization data
   from tickets used in a PA-TGS-REQ [CLAR] of the TGS-REQ to the
   resulting ticket.  Upon receipt of a service ticket carrying the
   AD-INITIAL-VERIFIED-CAS data, application servers MAY apply local
   policy to determine whether the authorization data is acceptable.

-- Larry

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

On Mon, Feb 07, 2005 at 10:14:46AM -0800, Paul Leach 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.

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.

> 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.)

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: Nicolas Williams <[email-masked]>
Date: Mon, 7 Feb 2005 14:59:18 -0600

> Good, we have a reason to remove it. 

That would be reason to remove it _later_.

> 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

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.

> are in such a late stage.

I don't agree.

> 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
--