Subject: [Ietf-krb-wg] FAST and RFC 4556

From: Sam Hartman <[email-masked]>
Date: Thu, 21 May 2009 07:37:59 -0400

I missed Love's message
https://lists.anl.gov/pipermail/ietf-krb-wg/2009-April/007614.html .
I'm not sure I understand it completely, but I think he brings up two
issues.  I wish I had seen this when Love sent it; I suspect we would
be happier solving this under less time pressure.

One, and I think more serious is the concern that FAST and RFC 4556
don't work together, because RFC 4556 is bound to the outer KDC
request body, which may be trivial.

Briefly, I believe that FAST introduces new attacks to PKINIT.  An
attacker who can establish a FAST tunnel with a KDC and who can obtain
a pk-as-req that the KDC will accept can cause a client to appear to
have authenticated with any set of kdc-req-body options of the
attacker's choice that the KDC will accept.  For example if a given
cert will be accepted for two principals, then the attacker can choose
one of these principals, even though the request was targeted for the
other.  Typically the attacker cannot  decrypt or use the resulting ticket.

An attacker who can mount a man-in-the-middle attack on a client
using pkinit and can establish a FAST tunnel with the KDC can cause
the client to authenticate with kdc-req-body selections of the
attacker's choice.  For example, an attacker could cause a user to
authenticate with longer tickets than they had expected.  This attack can only be mounted against the DH mode of RFC 4556; the RSA mode is not vulnerable.

I don't consider any of these attacks hugely serious, although they do
raise concerns because they are exactly the sort of attacks FAST was
intended to protect against.  As Love points out, if RFC 4556 were
designed as a FAST factor, none of these attacks would be possible: if
the client signed a hash of the FAST armor key and the KDC mixed the
armor key into the reply key, all attacks against RFC 4556 would be
defeated.  In other words, these are concerns about FAST interactions
with legacy mechanisms, not with future mechanisms.  This results from
choices in the FAST spec; it is possible that these choices could
create unfortunate interactions with other legacy mechanisms.

----------------------------------------

In detail: Larry and I made the decision that mechanisms such as RFC 4556
carried in FAST should use the outer not inner body to checksum
against.  At the time we thought this was a coin toss.

I now think we were wrong.  Our argument was that the FAST armor
protects the request.  For those who remember external-keyex from ssh,
this is roughly that all over again.

The FAST armor establishes a secure transport between two parties and
typically authenticates the identity of the KDC to the client.

Larry and I were thinking of the RFC 4556 checksum as a protection
for a client to make sure that an attacker did not modify the request
in transit.  That is, we believed the client was the party with
primary interest in that protection.  At least in the case where the
KDC is authenticated, the client does get that protection from the FAST channel.

However the KDC also needs to verify the correctness of the
information covered by that checksum,  new FAST factor would bind its
message to the armor key (or a checksum of the armor key) and achieve
this protection.  However RFC 4556 doesn't know about armor keys.

By choosing the outer checksum, we create a situation where the KDC
relies on the inner request to make decisions such as the requested
lifetime, but only protects the outer request.

This creates new attacks not present in Kerberos without FAST.  So far
I've not come up with any serious attacks, but it is an issue.

----------------------------------------

Solving this may be a bit tricky.  At least MIT is under tight
implementation time pressure.  Also, the more we change FAST,the more
we invalidate existing testing.  So, one option is to document this
and move on.  I'd probably recommend against using pkinit over FAST
protected by anonymous pkinit.  The other attacks seem acceptable for
a number of environments.  Personally I'd like to do better than this
option but not at the expense of interoperability.

The next easiest option is to change the checksum to cover the inner
request.  To stress the time constraints, I don't think I would feel
comfortable making that change and guaranteeing that I could
adequately test it in the MIT code base before the 1.7 release.  I
might be able to change the MIT client to always send identical outer
and inner requests and change the MIT KDC to check the inner request
body.  Hopefully this would not introduce interop issues.  

I want to make it clear that the WG is not required to work with MIT's
schedule.  However, we do value running code and interoperability, so
thinking about the issues introduced would be good.

I've thought of some more exotic options involving actually using the
armor key, but I definitely think those would be out of scope here.

Regardless of what we do to FAST, we can improve pkinit at some later date by binding it to the armor key when used with FAST.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Wed, 27 May 2009 02:25:18 -0400

> lifetime, but only protects the outer request.

After educating myself about PKINIT, I agree that this is not sound
design, although I can see how the attacks were not obvious.  The PKINIT
client padata is indeed bound to the inner body in that they are both
encrypted in the FAST armor key, but because the checksum is calculated
over the outer KDC-REQ body, there is no assurance that the client did
not copy the PKINIT padata from another source.

> implementation time pressure.

As Sam is aware, MIT has alleviated this time pressure by disabling
PKINIT under FAST for the initial 1.7 release.  It turns out that FAST
PKINIT was not working yet in our implementation anyway (in fact, I
believe the MIT KDC was calculating the checksum over the inner body,
while the client code was following the draft and using the outer body,
though I'm not certain of that).

So I believe the simplest solution now is to change FAST to specify that
PKINIT and similar mechanisms should checksum the inner KDC-REQ-BODY.

> Also, the more we change FAST,the more we invalidate existing testing.

I'm not sure what testing has been done outside of MIT's implementation,
but within the context of our implementation, all of the FAST PKINIT
testing was (I believe) done after this issue was understood, and with
the result that we hadn't integrated the two properly and it isn't
working yet.  So I'm not concerned about invalidating existing testing
in that context.