[Ietf-krb-wg] FAST and RFC 4556

[Sam Hartman <[e-mail]>]

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
[e-mail]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg