Subject: [Ietf-krb-wg] FAST: when to use FAST in a TGS request

From: Sam Hartman <[email-masked]>
Date: Fri, 20 Mar 2009 16:15:16 -0400

I've had a relatively easy time implementing FAST.  I found relatively
few issues where the draft didn'tanswer the questions I was looking
for or where it seemed wrong.  I've written messages about those few
cases over the last few weeks.

However there's one area where the draft falls short: when should a client use FAST to talk to the TGS.

I think I was assuming the answer is that you should use FAST to talk
to the TGS when you talked to the AS.  That's a bit tricky for the MIT
implementation because it involves finding somewhere to store whether
you have talked to the AS using FAST.
The MIT credential cache format is not that easy to extend; doing so
definitely requires coordination with other vendors.

Also, it turns out that's an incomplete answer.  How do you handle
cross-realm operation?

Another answer is to always try FAST.  That works, but the negotiation
is not protected.  IN particular, an attacker may remove the FAST
armored req from the request and the KDC has no way to tell that the
client tried to use FAST.
As a result, the client cannot tell if the KDC supports FAST.

Still, that's a potentially valid option.

However I've been thinking about how to do something better.

We could define a new authorization data element AD-FX-FAST-USED.  You
would include this either in your ticket or ap-req.  If present, it
would signal to a TGS that there better be a a FAST padata.
If no FAST padata is found, the TGS would reject the request.

Is it worth making this change at this point in the process?

--Sam
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Tue, 24 Mar 2009 09:55:06 -0700

I would prefer to standardize the encrypted padata in the KDC reply. This way the client can securely find out if the KDC supports FAST and it works for both AS and TGS.

I understand we have proposed to standardize the encrypted KDC reply in the referrals document but if we need to make a change, we might as well just make it happen here so that the preauth framework document is more self contained.

--Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Friday, March 20, 2009 1:15 PM
To: [email-masked]
Subject: [Ietf-krb-wg] FAST: when to use FAST in a TGS request

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Mar 2009 13:43:55 -0400

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

    Larry> I would prefer to standardize the encrypted padata in the
    Larry> KDC reply. This way the client can securely find out if the
    Larry> KDC supports FAST and it works for both AS and TGS.  

I thought about this.  The problem is that you cannot distinguish a
KDC that doesn't support FAST or enc_padata from a KDC who was
attacked by someone who stripped fast and the canonical flag.

so, you need the ad element even with the enc_padata.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Tue, 24 Mar 2009 11:12:07 -0700

Humm... And thanks for pointing that out.

TGS is safe against stripping of the canonical flag because of the TGS checksum computed over the KDC body which includes the KDC options field, so this won't be issue as long as the client is willing to supply the canonical flag all the time.

If it is unfair to require the support of the canonical flag (I can envision Martin would shout at me for proposing that), then we can add a KDC option to indicate that the client is updated to understand the encrypted KDC reply. If a new KDC option is too big a hammer then I would support the AD element then. In that case, let's put it in the IF-RELEVANT container in the AP-REQ authenticator of the pa-tgs-req padata, so that it is backward compatible and it is secure when the KDC is updated.

--Larry