Subject: RE: AD review for draft-ietf-krb-wg-ocsp-for-pkinit

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sun, 16 Jan 2005 19:03:07 -0800

Sam Hartman wrote:

> I think the security considerations section should mention the fact
that the OCSP 
> response is not bound to any particular 
> pkinit padata and discuss the implications of this.  

We have the following text from Nico.

   The pre-authentication data in this document do not actually
   authenticate any principals, and it is designed to be used in
   conjunction with PKINIT. 

Can you hint what threats you had in mind?

> It is my intent to hold the draft until pkinit catches up and to 
> ballot them together.

This sounds good. We will have code for this in the next month or two, 
that perhaps will also help to iron out any remaining issues.

-- Larry
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Sunday, January 16, 2005 11:53 AM
To: [email-masked]
Subject: AD review for draft-ietf-krb-wg-ocsp-for-pkinit

The draft looks good.  It is my intent to hold the draft until pkinit
catches up and to ballot them together.

I think the security considerations section should mention the fact that
the OCSP response is not bound to any particular pkinit padata and
discuss the implications of this.  

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 17 Jan 2005 09:37:34 -0500

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

    >> I think the security considerations section should mention the
    Liqiang(Larry)> that the OCSP
    >> response is not bound to any particular pkinit padata and

    Liqiang(Larry)> We have the following text from Nico.

    Liqiang(Larry)>    The pre-authentication data in this document do
    Liqiang(Larry)> not actually authenticate any principals, and it
    Liqiang(Larry)> is designed to be used in conjunction with PKINIT.

The pre-authentication data in this document are not bound to any
particular pkinit pre-authentication data.  They can be inserted or
removed by an attacker.  [explain why this is not a problem--I know it
isn't but we need to have clarifying text]

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 Jan 2005 11:46:54 -0600

> isn't but we need to have clarifying text]

I identified a variant of this problem very early on and there is text
about it: there is not integrity protection for the presence or absence
of this PA type.

The more generic problem is as Sam describes it: there is no binding
between the PKINIT and OCSP pre-auth data.

This is not a problem, as Sam surmises, because: a) stripping off the
OCSP responses amounts to, at most [but, see below], a DoS attack, which
Kerberos V does not protect against, and b) replacing OCSP responses on
the wire with others or with garbage is also, at most, a DoS attack as
OCSP responses for certificates not used in the PKINIT pre-auth will
simply be ignored.

Presumably KDCs will not issue tickets to holders of certificates whose
freshness cannot be validated, either through OCSP or by consulting a
CRL, if the KDC has any sort of certificate freshness policy.

Clients, OTOH, are worse off by just giving up on validating KDC
certificate freshness than KDCs, so if they proceed even when KDC certs
can't be ascertained to be fresh then an OCSP pre-auth stripping attack
could fool a client into...  talking to malicious services, possibly
handing sensitive information to them, and so on.  For such an attack to
work a KDC's private key must be compromised, in which case one likely
has bigger problems at hand.

I'll write some suitable security considerations text on this.

Cheers,

Nico
--