Subject: [Ietf-krb-wg] FAST LC: removing ap-req armor for TGS

From: Sam Hartman <[email-masked]>
Date: Tue, 16 Jun 2009 16:41:41 -0400

As you will recall, in a show of apathy, we decided there would be two
options for FAST TGS armor.  The first is to use the tgs-req
authenticator to build an armor key.  No actual element is sent in the
armor structure of FAST.  This is called implicit armor.

We also allow you to use a separate armor ticket (explicit ap-req
armor).  The intent was to allow people to use an armor ticket
different from the header ticket when validating, proxying or
otherwise presenting a non-TGT to the TGS.  I think I was one of the
main proponents of this option.

I seem to recall us admitting that we didn't have strong preferences
and that we were unsure this explicit armor was important.

I propose to remove it because it creates security problems and
implementation experience has shown it is difficult and unlikely to be
used.

Two implementers (myself and another) found that our implementations
made it very difficult to use explicit armor.  There wasn't really a
good way to find and select the armor ticket in the TGS path.  So, in
my implementation I created a special testing interface but did not
plan to use explicit armor for anything other than testing.

Larry discovered a weakness which ends up leading to a fairly minor
attack if explicit armor is available.

As you will recall, the ap-req in the pa-tgs-req has a checksum of the
outer request body.  However FAST KDCs use the inner request body.
So, an attacker can take an existing tgs-req and construct a FAST
TGS-req with a request body of the attacker's choice.  The attacker
can manipulate lifetimes, remove authorization data restrictions from
the request, manipulate addresses, or manipulate flags.

In general, this attack only allows the attacker to create bogus log
entries and auditing information.  The attacker will not know the
reply key, so the attacker cannot decrypt the kdc-rep and get the
session key.

If the KDC uses the strengthen key, then generating incorrect auditing
information is the worst we've been able to do.  Greg Hudson has found
a variation where an attacker may be able to observe a request for a
ad-fx-armor tgt and turn that into a request for a tgt without
ad-fx-armor if the strengthen key is not used.  In some environments
that could be fairly serious.

So, why is this possible?  There are a number of ways to look at that.
My argument is that we failed to note an important security property
of TGS armor.  TGS armor, unlike AS armor, must authenticate the
client to the KDC.  Implicit armor does this; explicit armor does not.

So, I propose to remove the support for ap-req armor from the TGS.  I
propose to note that any armor types designed for use with the TGS
must authenticate the client to the TGS and explain why that is true
for the implicit armor.

If we ever decide we do need explicit TGS armor, adding a version that
ties the armor key to the subsession key in the pa-tgs-req is entirely
doable.  I just don't think that makes sense at this point in the
process especially given that it ended up being fairly hard to use
explicit armor.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Wed, 17 Jun 2009 09:25:23 -0400

> must authenticate the client to the TGS and explain why that is true

I agree with this proposal.  (As Sam implied, I spent some time
analyzing this problem during a private discussion of the security
impact.)

---

From: Larry Zhu <[email-masked]>
Date: Thu, 18 Jun 2009 00:27:51 +0000

I agree with the proposal. Let's also require the strengthen-key key to be present in the TGS reply in order to ensure that the outer KDC request is cryptographically bound with the TGS request.

--Larry