Subject: [Ietf-krb-wg] FAST: ticket to use for fast TGS (responses desired)

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Jan 2009 14:51:59 -0500

One of the open issues from the Dublin lunch is the question of what
ticket to use as an armor ticket when proxying, validating, or
otherwise making a TGS request where the header ticket is not a TGT.
In my working copy of 09 I've closed this out by saying that you
always use a TGT; this is consistent with a requirement in the draft
that the service of the armor ticket be the TGS.

Unfortunately this is inconsistent with the requirement that the armor
element of KrbFastArmorReq be absent in a TGS request.

The simplest fix is to say that you always use the ticket in the
pa-tgs-req authenticator as the ticket for armor in a TGS request.

The problem with this is that both the service and the KDC know the
ticket key.  So the service could be aware of the channel and could
act as a man-in-the-midle between the client an the KDC.  Th is true
of Kerberos today.  However it would weaken the extent to which FAST
increases Kerberos security.  It would also mean that you relax some
of the checks by permitting invalid tickets, etc.

A more complicated fix is to allow armor to be present in the TGS
request and to use an explicit ticket if presented.  Then we could say
that clients SHOULD|MUST use an explicit armor ticket when the service
is not a TGS.  It complicates the spec somewhat, but more
significantly could complicate implementations a lot.  At least for
MIT and Heimdal, finding an appropriate TGT to use if you are not
given a TGT to start with may be tricky.

So:
* Should we permit explicit armor tickets to be specified in the TGS case or simply use the ticket presented to the TGS?
* Should we require that clients use a TGT if the ticket presented to the TGS is not one?

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Jan 2009 14:52:57 -0500

Folks, I could really use comments on this today or tomorrow.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Tom Yu <[email-masked]>
Date: Thu, 29 Jan 2009 16:02:41 -0500

> * Should we permit explicit armor tickets to be specified in the TGS
> case or simply use the ticket presented to the TGS?

Yes, but to simplify things, I would argue that we should only allow
an explicit armor ticket in TGS-REQ if the PA-TGS-REQ ticket is not
the local TGS.  I'm not quite sure yet how we should handle the case
for a cross-realm TGS.

> * Should we require that clients use a TGT if the ticket presented

I think we should make it a "SHOULD".
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Fri, 30 Jan 2009 11:43:57 -0800

For question #1, I think we should simply use the ticket in the PA-TGS-REQ of the TGS request. This way it is simple to implement. It is not clear to me what additional benefits we can offer by allowing alternative tickets to construct the armor. If we find it useful to allow alternative tickets in the future, we can always add it at that time. For now I would prefer a "minimalist "approach here.

Furthermore it seems counter-intuitive to use a normal service ticket in the AP_REQ of PA-TGS-REQ. Section 5.5.1 of RFC4120 says that the ticket in AP_REQ is to authenticate the client to the server and the server is the TGS in a TGS request, thus it won't be hard to deduce that the ticket in the PA-TGS-REQ *should* be one for the TGS intuitively.

For question #2, I would hesitate to add additional requirements in this document. In my reasoning above here, I suspect all the implementations out there are using TGTs anyway in the PA-TGS-REQ. I would also suggest we should add text in the security considerations section to encourage the use of TGTs in the PA-TGS-REQ structure.

--Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Tuesday, January 27, 2009 11:52 AM
To: [email-masked]
Subject: [Ietf-krb-wg] FAST: ticket to use for fast TGS (responses desired)

So:

--Sam

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 30 Jan 2009 15:01:19 -0500

--On Friday, January 30, 2009 11:43:57 AM -0800 Larry Zhu 
<[email-masked]> wrote:

> For question #1, I think we should simply use the ticket in the
> PA-TGS-REQ of the TGS request. This way it is simple to implement. It is
> not clear to me what additional benefits we can offer by allowing
> alternative tickets to construct the armor. If we find it useful to allow
> alternative tickets in the future, we can always add it at that time. For
> now I would prefer a "minimalist "approach here.
>
> Furthermore it seems counter-intuitive to use a normal service ticket in
> the AP_REQ of PA-TGS-REQ. Section 5.5.1 of RFC4120 says that the ticket
> in AP_REQ is to authenticate the client to the server and the server is
> the TGS in a TGS request, thus it won't be hard to deduce that the ticket
> in the PA-TGS-REQ *should* be one for the TGS intuitively.
>
> For question #2, I would hesitate to add additional requirements in this
> document. In my reasoning above here, I suspect all the implementations
> out there are using TGTs anyway in the PA-TGS-REQ. I would also suggest
> we should add text in the security considerations section to encourage
> the use of TGTs in the PA-TGS-REQ structure.

I think you're missing an important class of TGS requests, specifically, 
requests for the TGS to modify an existing ticket.  These include renewing 
tickets, forwarding tickets, and validating post-dated tickets.  In all of 
these cases, the ticket used to authenticate the TGS request is the ticket 
which the client is asking the TGS to modify, which is often not a TGT.

In the case where a client is asking the TGS to issue a new ticket, of 
course it must authenticate with a TGT, and of course that ticket should 
also be used for FAST armor.  I see no reason to permit anything else.

However, in cases where a client is asking the TGS to modify a non-TGT, I 
think it is desirable for the exchange to be protected by a real TGT, 
rather than only by the ticket being modified.  This prevents attacks on 
the TGS exchange by the application service, which, under the Kerberos 
model, is not trusted.

Thus, I believe we definitely _should_ permit an explicit armor ticket to 
be specified for a TGS exchange when the ticket being presented to the TGS 
is not a TGT.  I think it is fine to require in this case that the explicit 
armor ticket be a TGT.  This can be obtained by the client in any of the 
usual ways that would be used for an AS request (host TGT, anonymous 
PKINIT, anonymous-anonymous PKINIT), or using an existing TGT the client 
has, or in any other way the client finds useful.

I'm undecided on the question of whether clients should be required to do 
this, rather than simply using the ticket being presented to the TGS even 
when that is not a TGT.  I guess I'm inclined not to require it, since

- clients are not required to use FAST
- this is already an issue when not using FAST
- even without this requirement, using FAST is an improvement

-- Jeff

---

From: Larry Zhu <[email-masked]>
Date: Fri, 30 Jan 2009 12:20:12 -0800

Thanks for pointing out the use cases. My position to the two questions is the same. Thought I do not object removing the text that says the "armor" must be absent in TGS and instead we can say the armor key is specified in the armor field if that is present, otherwise it is derived from the ticket in the pa-tgs-request.

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]]
Sent: Friday, January 30, 2009 12:01 PM
To: Larry Zhu; Sam Hartman; [email-masked]
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] FAST: ticket to use for fast TGS (responses desired)

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Fri, 30 Jan 2009 16:11:16 -0500

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

    Larry> Thanks for pointing out the use cases. My position to the
    Larry> two questions is the same. Thought I do not object removing
    Larry> the text that says the "armor" must be absent in TGS and
    Larry> instead we can say the armor key is specified in the armor
    Larry> field if that is present, otherwise it is derived from the
    Larry> ticket in the pa-tgs-request.  -----Original Message-----

I'm going to do this.

Here's why.

A lot of people have been talking about wanting to make this easy to
implement.  That is a significant concern to me and a lot of other
people.  At least some people seem to want to be able to use a TGT
even when the ticket being sent to the TGS is not one.

I've been thinking about implementing FAST a lot in the last couple of
days.  The easiest thing to implement would be if the armor was always
present and the PA-TGS-REQ were inside the KRBFastArmoredReq.
We don't want to do that as it may tend to double the size of TGS requests.

So, the next easiest thing to do for the server is to look for either
an armor value or a pa-tgs-req and pull the ticket out of whatever one
we find.

People have proposed various restrictions on top of that:

* Prohibit clients from using the armor field if they are sending a
TGT to the server.  I certainly cannot see why a client would desire
to do something else, although I don't feel that strongly about it.  I
cannot see a security or interoperability reason that a client MUST
use the same TGT.  I think the only thing adding a MUST here will do
is possibly complicate the implementation of servers if someone tries to enforce the MUST.

* I don't think there is currently consensus to require clients to use
  the armor TGT if they are sending a non-TGT.  Unless such a
  consensus emerges I'm going to permit a non-TGT to be used to get
  the armor key in such cases.  My reasoning is two-fold: first, there
  doesn't seem to be a consensus.  Secondly, it seems easier to
  implement clients ( at least for MIT and Heimdal) if this behavior
  is permitted.

I fully understand that all of the above is subject to the consensus
of the WG and the discussion is not done yet.  I also realize I'm
stretching the role of the editor somewhat.  However I really want to
submit a draft that to the best of my ability is self-consistent and
complete.  Obviously if the WG comes to a different conclusion or I am
directed by the chair, I will do as directed.

---

From: Larry Zhu <[email-masked]>
Date: Fri, 30 Jan 2009 13:25:58 -0800

Hi Sam,

Given no one really has indicated a strong opinion one way or the other so far, I support your approach as an individual.

--Larry

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]]
Sent: Friday, January 30, 2009 1:11 PM
To: Larry Zhu
Cc: Jeffrey Hutzelman; [email-masked]
Subject: Re: [Ietf-krb-wg] FAST: ticket to use for fast TGS (responses desired)

I'm going to do this.

Here's why.