Subject: [Ietf-krb-wg] TGS binding and FAST

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Feb 2009 16:59:08 -0500

There seems to be a bit of a problem with our plan to allow armor
tickets in TGS.  If the ticket from pa-tgs-req is used for armor, and
a subkey is used, then the pa-tgs-req is clearly bound to the fast
request.

However if an armor ticket is used, there doesn't seem to be anything
that binds the pa-tgs-req to FAST.  The checksum in the pa-tgs-req is
over the outer kdc req body, not the inner one.

It seems like you can substitute a pa-tgs-req from one request for a
pa-tgs-req from another request within some constraints.  One of the
bigger ones is that unless FAST replaces the reply key, the reply key
will be different because a different subsession key should be
included.  However that doesn't allow the KDC to detect the
substitution, only creates problems for the client.

An easy fix is to reverse our decision that permits armor tickets to
be used with the TGS.  That's not a great solution because of the
issues we discussed.

This does not come up with AS requests because there is no pa-tgs-req.

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

---

From: Larry Zhu <[email-masked]>
Date: Thu, 12 Feb 2009 23:35:48 -0800

It does not seem to be an issue though. The KrbFastResponse padata is required in the response if the KDC supports FAST and the "finished" field in that structure provides the necessary binding. If the TGS does not support FAST, the binding is not needed, right?

It seems to me that the current wording can be made a bit more clear in term of what is expected in the TGS case.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Feb 2009 08:26:28 -0500

Yes,  but the problem is that the KDC  will never know if things went badly.
I'm not sure how big of a deal this is.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Feb 2009 10:45:06 -0500

So, I'm still not sure if we should fix this.  Here are some fixes though if we decide we want to.

* In the TGS case, checksum the pa-tgs-req instead of the kdc-req-body
  in the fast request.  This is clearly secure, involves no more
  overhead, but is ugly and means TGS processing is different than AS
  processing.

* Add a TGS-specific checksum of the PA-TGS-REQ.
This is also clearly secure, is architecturally cleaner, involves longer packets and doesn't seem to be a win over the last option.

* Forbid TGS armor tickets.  Some of us are uncomfortable with the
  properties of that, but it definitely solves this problem.

--Sam

---

From: Larry Zhu <[email-masked]>
Date: Fri, 13 Feb 2009 09:42:37 -0800

#1 is not backward compatible because the TGS might not support FAST and we have not defined a way to detect if the TGS supports FAST offically.

Yet another solution is to always include a copy of pa-tgs-req within the FAST padata. It seems to be consistent in that everything goes into FAST that way.

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]]
Sent: Friday, February 13, 2009 7:45 AM
To: Larry Zhu
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] TGS binding and FAST

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Feb 2009 14:19:07 -0500

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

    Larry> #1 is not backward compatible because the TGS might not
    Larry> support FAST and we have not defined a way to detect if the
    Larry> TGS supports FAST offically.  

I'm confused.
#1 is updating FAST to say that the checksum in the KRBFastReq  is of the pa-tgs-req for TGS and of the kdc-req-body for AS.
You say this is not compatible because we don't know if the TGS supports FAST.

However, if the TGS is decoding a KrbFastReq, then it seems like it
can be assumed to support FAST.

I agree that including a pa-tgs-req in fast will solve the problem.
It is kind of messy to implement though because you have to have the
pa-tgs-req outside of fast when it is telling you what armor to use,
but you have to have it inside when you have another armor ticket.

--Sam

---

From: Larry Zhu <[email-masked]>
Date: Fri, 13 Feb 2009 12:01:00 -0800

> You say this is not compatible because we don't know if the TGS supports FAST.

I thought you proposed to change pa-tgs-req. That is not the case so this is a red herring.

> but you have to have it inside when you have another armor ticket.

Good catch. How about pa-tgs-req must not be included in FAST if the armor ticket is not present.

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]]
Sent: Friday, February 13, 2009 11:19 AM
To: Larry Zhu
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] TGS binding and FAST

I'm confused.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Feb 2009 15:32:04 -0500

Larry> Sam Hartman wrote:
    >> I'm confused.  #1 is updating FAST to say that the checksum in
    >> the KRBFastReq is of the pa-tgs-req for TGS and of the
    >> kdc-req-body for AS.  You say this is not compatible because we
    >> don't know if the TGS supports FAST.

    Larry> I thought you proposed to change pa-tgs-req. That is not
    Larry> the case so this is a red herring.

    Larry> Sam Hartman wrote:

    >> I agree that including a pa-tgs-req in fast will solve the
    >> problem.  It is kind of messy to implement though because you
    >> have to have the pa-tgs-req outside of fast when it is telling
    >> you what armor to use, but you have to have it inside when you
    >> have another armor ticket.

    Larry> Good catch. How about pa-tgs-req must not be included in
    Larry> FAST if the armor ticket is not present.

It's well defined.  It's just that your code needs to deal with both
the pa-tgs-req and the armor ticket being in different places.

That seems like a fair bit of complexity.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg