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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sun, 6 Feb 2005 20:38:15 -0800

Nicolas Williams wrote:
> We long ago decided that AD-INITIAL-VERIFIED-CAS is *critical* (as
critical as the 'transited' field of Ticket).

That is precisely why we should reconsider. Current SSPI deployments
would just ignore this.

-- Larry

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

On Sun, Feb 06, 2005 at 07:51:20PM -0800, Liqiang(Larry) Zhu wrote:
> 
> From clarifications:
> 
>    Implementation note: Many RFC 1510 implementations ignore unknown
>    authorization data elements. Depending on these implementations to
>    honor authorization data restrictions may create a security
weakness.
> 
> Unless there is significant benefit causing deployed server 
> applications to fail when PKINIT is used, we propose to always wrap 
> this auth-data in the AD-IF-RELEVANT container.
> 
> Any comments?

We long ago decided that AD-INITIAL-VERIFIED-CAS is *critical* (as
critical as the 'transited' field of Ticket).

So, no, I don't agree to this change at this late stage.

I would agree to a MAY though: the TGS MAY wrap AD-INITIAL-VERIFIED-CAS
in an AD-IF-RELEVANT authorization-data element.  I'm not sure that such
text is at all needed though -- who will complain if a KDC
implementation supports wrapping, or excluding AD-INITIAL-VERIFIED-CAS
on a per-service principal basis?

If direction need be given as to when it's ok to wrap it then I'd
propose: "The TGS MAY wrap AD-INITIAL-VERIFIED-CAS in an AD-IF-RELEVANT
authorization-data container elmenent, or exclude it all together, if:
a) the KDC knows a priori that the ticket's service principal does not
implement support for AD-INITIAL-VERIFIED-CAS, b) the ticket's service
principal is not a cross-realm TGS principal name, and c) realm policy
on PKINIT client certificate validation paths is sufficient."

Also, I'm not sure that I would agree that KDCs should or must be
configurable in this regard.

But really, though I might want to implement such a feature I'm not sure
we need the spec to say a word about it.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 6 Feb 2005 22:38:33 -0600

> That is precisely why we should reconsider. Current SSPI deployments

That harms interop not and nothing the KDC can do, other than refuse to
issue the ticket, will redress the security problem (that the service
can't apply a policy to the AD-INITIAL-VERIFIED-CAS ad element).

Nico
--