Subject: Signing preauth authentication sessions

From: [email-masked] (Sam Hartman)
Date: Thu, 15 Jul 2004 18:59:58 -0400 (EDT)

Shortly after the last IETF, Love and I discussed the preauth
framework.

There's an important issue I've made very little progress on and could
use significant design assistance from the working grou.

The question is how do we want to checksum preauthentication sessions?

I originally thought that at least for extensions, this problem would
be solved because the kdc-rep would include a checksum of the most
recent as-req in the reply key.  

However this is not sufficient for multi-round-trip mechanisms.

All the solutions I've thought of for this seem complicated.  I was
thinking along the lines of having the client and KDC accumulate some
sort of checksum of the entire session.  However it seems that
specifying that behavior clearly would be difficult.

Thoughts or alternatives?

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Jul 2004 12:50:34 -0400

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    Sam> Shortly after the last IETF, Love and I discussed the preauth
    Sam> framework.

    Sam> There's an important issue I've made very little progress on
    Sam> and could use significant design assistance from the working
    Sam> grou.

    Sam> The question is how do we want to checksum preauthentication
    Sam> sessions?

Nico was a bit confused by what problem I'm trying to solve so I
thought I would clarify.  The preauth exchange forms a negotiation; we
want to protect this negotiation against modification.  However we may
not have key material until the exchange concludes.

Nico proposed accumulating a checksum in successive exchanges; the
client would include a checksum of past exchanges for the KDC to echo
back, etc.
I'm still trying to see if such an exchange can be made to be proof
against a man in the middle.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 16 Jul 2004 13:32:49 -0500

> against a man in the middle.

Thinking about it more:

 - have a method for doing all this binding and state tracking, with

    - an accumulator checksum set by the client and repeated by the
      server (optional; used in multi-round-trip AS exchanges)

    - per-actual pre-auth state set by the server and repeated by the
      client (optional; used in multi-round-trip AS exchanges where
      state, including integrity protection of earlier messages, is
      needed by the KDC)

    - a signature of the above that is included as soon as suitable key
      material is available

 - this method should logically, if not actually, contain all actual
   pre-auth to be bound through it; if we need to control, on the wire,
   the way in which other pre-auths interact, then the necessary
   facility should be provided here

 - this method could be a pseudo-pre-auth mechanism.

Protection against MITMs will then depend on the actual pre-auths used
and their combinations.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 16 Jul 2004 21:02:15 +0200 (MET DST)

I'm wondering what the exact benefit of integrity protection
of preauth data is, and if really all of the preauth data actually
needs it, i.e. in which cases is there a undetectable vulnerability
when the (PKINIT) authentication succeeds which can be entirely
prevented by the use of an authenticated checksum?

Or is this to provide a general protection scheme to protect
vulnerable negotiations that may be proposed/used in the future?

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Jul 2004 15:15:58 -0400

How do we choose what unkeyed checksum to use for this stuff?  I think
the answer is fairly obvious today: use sha-1.  But how do we
negotiate it?

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Jul 2004 16:20:04 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> I'm wondering what the exact benefit of integrity
    Martin> protection of preauth data is, and if really all of the
    Martin> preauth data actually needs it, i.e. in which cases is
    Martin> there a undetectable vulnerability when the (PKINIT)
    Martin> authentication succeeds which can be entirely prevented by
    Martin> the use of an authenticated checksum?

It's clear that not all preauth needs authenticated checksums.  It is
hopefully true that there are no vulnerabilities if pkinit is not
authenticated because it happens not to be.  The fact that I've never
fully convinced myself that pkinit has no unauthenticated cleartext
vulnerabilities decreases my confidence in the specification.  I'm
reasonably certain that any vulnerabilities are small, but getting to
that certainty required more review than I liked.

From my standpoint, a significant motivation for the preauth framework
has been the difficulty I've had coming to grips with pkinit security
requirements.  It's clear that there are a lot of cases where not
authenticating some cleartext in Kerberos has been problematic.  The
most obvious of these is the fact that the ticket can be substituted
in the KDC reply .

Several of us who are spending significant time on Kerberos
specification decided that we believe stronger security guarantees
would make our job as protocol designers easier.

It's fairly easy to see that protecting some preauth exchanges is
valuable.  For example, protecting the exchange of the initial list of
mechanisms offered by the KDC serves the same purpose as signing the
mechanism lists in SPNEGO.

So, is it worth authenticating all preauth?  I'm not sure.  If it is
relatively easy to do, then certainly yes.  However it is proving
challenging to do correctly.  I may end up finding a solution and
recommending that the working group not solve the full problem because
the solution introduces too much complexity.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Jul 2004 16:53:05 -0400

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

    Nicolas> Thinking about it more:

    Nicolas>  - have a method for doing all this binding and state
    Nicolas> tracking, with

    Nicolas>     - an accumulator checksum set by the client and
    Nicolas> repeated by the server (optional; used in
    Nicolas> multi-round-trip AS exchanges)

I don't understand how to make this work.  

Let's focus on the first message from the KDC to the client.  This is
an important one to protect because it includes the initial list of
preauth mechanisms.  

Somehow this message needs to get included in some checksum that the
KDC verifies.  The client can checksum the message, but the client
does not know whether the message was modified in transit.  At the end
of the exchange, the client can securely tell the KDC what it received
for this message, but the KDC no longer has any idea what it sent for
the second message.

From a computability/complexity standpoint it is possible for the
second message from the KDC to the client to include a copy of itself
but that's going to be kind of complex.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 16 Jul 2004 16:27:23 -0500

> I don't understand how to make this work.  

s/set by the client and repeated by the server//

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Jul 2004 17:44:41 -0400

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

    Nicolas> On Fri, Jul 16, 2004 at 04:53:05PM -0400, Sam Hartman
    Nicolas> wrote: - an accumulator checksum set by the client and
    Nicolas> repeated by the server (optional; used in
    Nicolas> multi-round-trip AS exchanges)
    >>  I don't understand how to make this work.

    Nicolas> s/set by the client and repeated by the server//

How does that work?  Please actually walk through an exchange; every
time I've tried to do that I find an attack.

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 17 Jul 2004 16:16:25 -0500

> time I've tried to do that I find an attack.

Sorry, I was in a hurry and didn't think about it.

I assume servers won't need to keep state to remember what methods they
offered, yes?