Subject: [Ietf-krb-wg] weak armor tgt

From: "Srinivas Cheruku" <[email-masked]>
Date: Mon, 25 May 2009 15:51:13 +0530

Sam,

The draft says that the armor tgt should be acquired from kdc using the host
keys.

But nothing stops the KDC in using any TGT as armor ticket. Is this ok?

What if a TGT got using a weak password/keys used as armor ticket?

Maybe, KDC should check for AD-fx-fast-armor in the ticket in AP-REQ in
armor-data and then only allow this ticket as armor ticket to get the actual
TGT?

The KDC can return a new kerberos error if AD-fx-fast-armor is not available
in the ticket in AP-REQ in armor-data.

Thanks,
Srini

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

---

From: Greg Hudson <[email-masked]>
Date: Mon, 25 May 2009 10:31:15 -0400

> What if a TGT got using a weak password/keys used as armor ticket?

Yes and no.

The armor key is derived from two randomly selected, presumably strong
keys: the ticket session key (selected by the server) and the TGS subkey
(selected by the client).

So, the problem in your scenario would arise when you obtained the
ticket for the armor key without using FAST, not during the FAST
exchange itself.  An attacker could conduct a dictionary attack against
the armor ticket to determine the long-term key, use that to decrypt the
non-FAST AS-REQ response to find the session key, use that to find the
TGS subkey, and then combine those two and use that to decrypt the FAST
exchange.

An eventual solution is for the KDC to disallow non-FAST AS-REQs for
principals with password-determined keys.

---

From: Tim Alsop <[email-masked]>
Date: Mon, 25 May 2009 16:34:52 +0100

Greg,

I understand that the AD-fx-fast-armor authorization data is used, so that a TGT issued as an armor TGT cannot be used to request service tickets from KDC TGS. This implies that only TGTs which were not for FAST Armor, are to be used for requesting service tickets. So, why not take this a step further and make the KDC check if the same authorization data is present when the TGT is sent as an armor TGT ?

Thanks,
Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Hudson
Sent: 25 May 2009 15:31
To: Srinivas Cheruku
Cc: [email-masked]; 'Sam Hartman'
Subject: Re: [Ietf-krb-wg] weak armor tgt

Yes and no.

---

From: Greg Hudson <[email-masked]>
Date: Mon, 25 May 2009 11:50:29 -0400

On Mon, 2009-05-25 at 16:34 +0100, Tim Alsop wrote:
> I understand that the AD-fx-fast-armor authorization data is used, so
> that a TGT issued as an armor TGT cannot be used to request service
> tickets from KDC TGS. This implies that only TGTs which were not for
> FAST Armor, are to be used for requesting service tickets. So, why not
> take this a step further and make the KDC check if the same
> authorization data is present when the TGT is sent as an armor TGT ?

What would this accomplish?

I can tell you what it would cost: say you log into a Unix system, and
pam_krb5 uses the host key to do a FAST exchange with the KDC to get you
tickets.  Nine hours later, you want to get new tickets.  But since
you're not logging in, you don't have access to the host key.
Currently, you could use your existing tgt cache as an armor ticket if
it hasn't expired, and prevent the new as-req exchange from being
observed and used to dictionary attack your key.  If the KDC insists on
seeing AD-fx-fast-armor in the armor ticket, then you would lose that
ability.

---

From: Tim Alsop <[email-masked]>
Date: Mon, 25 May 2009 19:19:06 +0100

Greg,

The pam module needs to use host key (from keytab) to get a FAST Armor TGT and store this in the armor ticket cache. The users TGT issued using this armor tgt will expire at same time, or very soon after the armor tgt. So, using your example I cannot think of a case where a users tgt has nearly expired and it is not possible to request a new armor tgt using the same key that was used to get the original armor tgt. Surely the user would use the same armor tgt that the pam module used to get the original TGT for the user ?

In summary - I cannot think of a use case where a user might want to use the TGT for their own user account as an armor TGT to get a new TGT. I think it is better to always use the same armor tgt that the pam module used to get the initial TGT for the user. Perhaps there is a reason for doing what you suggest - if so, can you explain ?

Thanks,
Tim

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 25 May 2009 15:16:19 -0400

On May 25, 2009, at 14:19, Tim Alsop wrote:
> The pam module needs to use host key (from keytab) to get a FAST  
> Armor TGT and store this in the armor ticket cache. The users TGT  
> issued using this armor tgt will expire at same time, or very soon  
> after the armor tgt. So, using your example I cannot think of a case  
> where a users tgt has nearly expired and it is not possible to  
> request a new armor tgt using the same key that was used to get the  
> original armor tgt. Surely the user would use the same armor tgt  
> that the pam module used to get the original TGT for the user ?

If local realm policy limits the lifetime (or renewable lifetime) of  
all TGTs, that will apply to the armor ticket as well.

-- 
Ken Raeburn / [email-masked] / no longer at MIT Kerberos Consortium

---

From: Tim Alsop <[email-masked]>
Date: Mon, 25 May 2009 23:08:32 +0100

Ken,
Yes, this is true.

The point we are trying to make in this thread is ... The authorization data is added to a ticket issued to authorize it for use as an armor tgt so that it cannot be used to request service tickets. So, surely it is also sensible to check that the tgt used as an armor tgt includes this same authorization data and if not, then it should be considered as a TGT which is not authorized for armor purposes and rejected ? Instead, the suggestion from Greg is that ALL tgt's should be used for armor tgt and no authorization is necessary to restrict usage. I am not clear why ALL tgt's should be allowed to be used for armor purposes.

Thanks,
Tim

---

From: Greg Hudson <[email-masked]>
Date: Mon, 25 May 2009 19:14:13 -0400

On Mon, 2009-05-25 at 19:19 +0100, Tim Alsop wrote:
> The pam module needs to use host key (from keytab) to get a FAST Armor
> TGT and store this in the armor ticket cache. The users TGT issued
> using this armor tgt will expire at same time, or very soon after the
> armor tgt. So, using your example I cannot think of a case where a
> users tgt has nearly expired and it is not possible to request a new
> armor tgt using the same key that was used to get the original armor
> tgt. Surely the user would use the same armor tgt that the pam module
> used to get the original TGT for the user ?

In the scenario I described (which I believe would be typical for Unix
logins), you would not have access to the armor ticket, and certainly
not to the host key used to get it, once you've finished logging in.

Even if you had access to the armor ticket, that would only help for the
first renewal, not the second or later.

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Tue, 26 May 2009 10:44:32 +0530

> Sent: 25 May 2009 21:20

[Srinivas Cheruku] it make sense. I believe a good approach for ticket
renewals. 

Thanks,
Srini

---

From: Tim Alsop <[email-masked]>
Date: Tue, 26 May 2009 07:35:36 +0100

In the scenario I described (which I believe would be typical for Unix
logins), you would not have access to the armor ticket, and certainly
not to the host key used to get it, once you've finished logging in.
[Tim Alsop] How ? Are you suggesting that the keytab file that contains the host key is only readable by root ?

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 26 May 2009 03:00:47 -0400

On May 26, 2009, at 02:35, Tim Alsop wrote:
> [Tim Alsop] How ? Are you suggesting that the keytab file that  
> contains the host key is only readable by root ?

I would certainly hope so.  Otherwise, anyone who can read it can  
decode anyone else's authenticators for the host service snooped off  
the wire (including the session and optional subsession keys, allowing  
them to decrypt or forge later traffic in the session), and forge  
authenticators to the host claiming to be (authentically, as far as  
the host can tell) anyone they wanted to be.

At least in some environments, the host principal is sometimes also  
used as a client identity to initiate system batch jobs requiring  
network authentication.  Anyone with read access to the keytab file  
can do that, as well.

---

From: Tim Alsop <[email-masked]>
Date: Tue, 26 May 2009 08:28:27 +0100

Ken,

Thankyou for explaining. I have no experience of using pam modules and host keys in this way - instead, we focus on application level security using GSS.

I am now clear that there is a valid use case to allow any principal to be used as an armor.

Regards,
Tim

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Tue, 26 May 2009 13:19:12 +0530

> seeing AD-fx-fast-armor in the armor ticket, then you would lose that

[Srinivas Cheruku] I was thinking more into this and it is good to use the
TGT as armor ticket to renew when the TGT was got using FAST. 
But at the same time, we can use any TGT as armor ticket e.g. TGT got using
non-FAST and might be having weak keys which might cause the FAST request to
compromise. 
This is the case I was thinking and I believe we need to restrict in some
way that weak TGTs are not used as armor tickets

1. We can have ticket flag saying that the TGT got using FAST, so that this
can be checked and will work for case of renew TGTs.
2. We can check for AD-fx-fast-armor authorization data in the armor ticket.
 2.1. We can have a policy at KDC that says which principals can be used to
get armor ticket. 
 2.2. Doing so would restrict the principals being used to get armor tickets
and we can restrict the usage of stronger keys for these principals
 2.3. When armor ticket is got for these principals, anyway AD-fx-fast-armor
auth data is added which can be checked.

Am not sure, but might be complicating things.

Thanks,
Srini

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 26 May 2009 04:26:00 -0400

> non-FAST and might be having weak keys which might cause the FAST  

The armor isn't bullet-proof. :-)
Yes, it's possible that the initial TGT was acquired with a weak  
password and no additional protection, so if someone recorded both  
that exchange and the new FAST exchange, a compromise might be  
possible.  But the new exchange is, I think, still no weaker than the  
initial one, is it?  And you're assuming an environment where kinit  
after login attempts to use a more secure mechanism than login itself;  
I hope that, if anything, the reverse is more likely.

It's also possible, if the initial host-key-based FAST exchange was  
recorded, that a later compromise of the host key could compromise the  
recorded authentication exchanges and the protection of sessions based  
on them.

Adding PFS would help here, so compromising the host key and looking  
at recorded traffic isn't enough to decode the traffic.  I've touched  
on some of this before.  A FAST factor using some ZKPP protocol,  
ideally with key exchange (in which case it might provide the armor as  
well), would help a lot.  One trick seems to be finding one that, by  
itself and when adapted to fit into Kerberos, isn't covered by some  
troublesome patent....

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 May 2009 09:02:41 -0400

>>>>> "Srinivas" == Srinivas Cheruku <[email-masked]> writes:

    Srinivas> Sam, The draft says that the armor tgt should be
    Srinivas> acquired from kdc using the host keys.

    Srinivas> But nothing stops the KDC in using any TGT as armor
    Srinivas> ticket. Is this ok?

Let's take a look at it.

Let's assume there are three parties involved.  There is a client, an
independent attacker and the KDC.
(The client or KDC may also have adverse interests, especially until they prove their identities to each other)

So, I think what you are asking is who benefits from a weak armor
ticket and can they set things up so a weak armor ticket is used.

Clearly, the independent attacker benefits from a weak armor ticket.
IT may make the entire exchange easier to attack if the long-term key
of the armor ticket is brute forced or if the reply key of the AS-REQ
used to obtain the armor ticket is brute forced.

Clearly, if the KDC wants to weaken the armor ticket, it could do so.
However if the KDC and attacker are cooperating, far more serious
attacks exist.

My assumption has been that the client has an interest in keeping the
armor ticket strong.  If the client wants to weaken the armor ticket
then it can disclose part or all of the armor key.

So, here are some questions for you.
Can the attacker force the client to use a weak armor ticket?
Does the client or the KDC have an incentive to use a weak armor ticket rather than leaking part of the armor key?
My assumption has been that the answers to both questions is no.

In particular, the obvious attacks to substitute one ticket for
another end up with the client with a ticket but without knowing the
session key.  Such a ticket cannot successfully be used as an armor
ticket.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 May 2009 09:06:52 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    Greg> On Mon, 2009-05-25 at 16:34 +0100, Tim Alsop wrote:
    >> I understand that the AD-fx-fast-armor authorization data is
    >> used, so that a TGT issued as an armor TGT cannot be used to
    >> request service tickets from KDC TGS. This implies that only
    >> TGTs which were not for FAST Armor, are to be used for
    >> requesting service tickets. So, why not take this a step
    >> further and make the KDC check if the same authorization data
    >> is present when the TGT is sent as an armor TGT ?

    Greg> What would this accomplish?

I also don't see what it would accomplish.

    Greg> I can tell you what it would cost: 

[Greg describes the pam-krb5 situation].

Actually, I think all it would cost would be an extra round trip.
With the exception of KDC issued authorization data (and similar
authorization data), AD elements are restrictions, not permissions.  A
client can easily request an AD element be added to a ticket.  For
example there is a test program in the MIT Kerberos release that will
ask the KDC to add ad-fx-armor to a ticket.

So, if we believe that we need to restrict the set of armor tickets,
we're going to need to do so in a way different than using
ad-fx-armor.  Coming up with such a mechanism is relatively easy.
What I have not done is come up with a reason why we'd want to do so
or what classification to use for what would be strong armor tickets.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 May 2009 09:08:23 -0400

>>>>> "Tim" == Tim Alsop <[email-masked]> writes:

    Tim> Ken, Yes, this is true.

    Tim> The point we are trying to make in this thread is ... The
    Tim> authorization data is added to a ticket issued to authorize
    Tim> it for use as an armor tgt 

That's not how Kerberos works.

It's added as a restriction
    Tim> so that it cannot be used to
    Tim> request service tickets. 
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 May 2009 09:16:21 -0400

>>>>> "Ken" == Ken Raeburn <[email-masked]> writes:

    Ken> On May 26, 2009, at 03:49, Srinivas Cheruku wrote:
    >> [Srinivas Cheruku] I was thinking more into this and it is good
    >> to use the TGT as armor ticket to renew when the TGT was got
    >> using FAST.  But at the same time, we can use any TGT as armor
    >> ticket e.g. TGT got using non-FAST and might be having weak
    >> keys which might cause the FAST request to compromise.

    Ken> The armor isn't bullet-proof. :-) Yes, it's possible that the
    Ken> initial TGT was acquired with a weak password and no
    Ken> additional protection, so if someone recorded both that
    Ken> exchange and the new FAST exchange, a compromise might be
    Ken> possible.  But the new exchange is, I think, still no weaker
    Ken> than the initial one, is it?  

Consider the OTP case.  Some of the OTP varients (the secure ID-no-key
case for example) would be completely insecure without FAST.  So, in
cases where Kerberos works today, weak armor doesn't decrease the
security over today's Kerberos (*), but FAST also enables new
deployments.  IN some of these, armor security seems important.
However I don't understand how a reasonable client ends up with weak
armor.

    Ken> And you're assuming an
    Ken> environment where kinit after login attempts to use a more
    Ken> secure mechanism than login itself; I hope that, if anything,
    Ken> the reverse is more likely.

As do I.

(*) At least, that's the goal.  As Love pointed out, with RFC 4556
we're not there yet.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Tim Alsop <[email-masked]>
Date: Tue, 26 May 2009 15:16:24 +0100

Sam,

Thankyou, I appreciate your input.

I understand that the AD-fx-fast-armor authorization data is currently used to stop KDC issuing service tickets when the TGT in request is an armor TGT. This suggests that the client software will need to request authorization data when it needs an armor TGT. However, the client can also request a TGT without the authorization data and use this as an armor TGT. The armor TGT can then be used to request service tickets, thus making the AD-fx-fast-armor pointless.

Thanks,
Tim

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 May 2009 10:31:04 -0400

>>>>> "Tim" == Tim Alsop <[email-masked]> writes:

    Tim> Sam, Thankyou, I appreciate your input.

    Tim> I understand that the AD-fx-fast-armor authorization data is
    Tim> currently used to stop KDC issuing service tickets when the
    Tim> TGT in request is an armor TGT. This suggests that the client
    Tim> software will need to request authorization data when it
    Tim> needs an armor TGT. However, the client can also request a
    Tim> TGT without the authorization data and use this as an armor
    Tim> TGT. The armor TGT can then be used to request service
    Tim> tickets, thus making the AD-fx-fast-armor pointless.

    Tim> Thanks, Tim

No, the point of ad-fx-armor is explained in the draft.  It only comes
up when you have a privileged part of the system that is able to read
the host key and a less privileged part of the system that wants to do
FAST.  The more privileged part of the system needs to have a
mechanism for preventing abuse by the less privileged part of the
system.  That's the point of ad-fx-armor.

Today, I'm not aware of implementations structured this way.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Tim Alsop <[email-masked]>
Date: Tue, 26 May 2009 16:41:34 +0100

Sam,

What kind of abuse are you suggesting might occur ? Are you referring to the possibility that the user might gain access to the credentials cache that contains the armor tgt and use this TGT to request service tickets ? If so, surely this credentials cache would be protected using the same operating system protection that would protect the key table file used to get the armor TGT by the privileged part of the system ?

Thanks,
Tim

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]]
Sent: 26 May 2009 15:31
To: Tim Alsop
Cc: Sam Hartman; Ken Raeburn; [email-masked]
Subject: Re: [Ietf-krb-wg] weak armor tgt

    Tim> Thanks, Tim

---

From: Greg Hudson <[email-masked]>
Date: Tue, 26 May 2009 12:02:18 -0400

On Tue, 2009-05-26 at 16:41 +0100, Tim Alsop wrote:
> What kind of abuse are you suggesting might occur ? Are you referring
> to the possibility that the user might gain access to the credentials
> cache that contains the armor tgt and use this TGT to request service
> tickets ? If so, surely this credentials cache would be protected
> using the same operating system protection that would protect the key
> table file used to get the armor TGT by the privileged part of the
> system ?

The idea is that you might want to do the network communication and
computation of FAST in a process without the privileges necessary to
access the host key, but without giving that unprivileged process
unfettered access to the capabilities of the host key.

As Sam notes, this sort of setup is a bit exotic, and is not what we
expect to see in early FAST deployments.  The best analogy I have seen
(only that it incorporates the "separation of privileges" doctrine) is
the OpenSSH privsep architecture.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 26 May 2009 12:15:20 -0400

> the OpenSSH privsep architecture.

I don't think it's as exotic as you suggest.  The idea is that kinit 
running as an ordinary unprivileged user can invoke a privileged helper to 
obtain a host-key-derived armor TGT, which it then uses in FAST.  In such a 
situation, you would not want the unprivileged user to be able to use that 
TGT to request tickets.

Essentially, the AD restriction allows construction of a ticket which is 
used to carry a key but cannot be used for authentication.

-- Jeff

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 26 May 2009 15:01:12 -0400

> However I don't understand how a reasonable client ends up with weak

Well, yes, how you get the weak armor is important.  I'm guessing that  
maybe pam_krb5 doesn't get updated for FAST and the password is weak,  
but later the user tries an updated kinit with FAST.  But if the  
password is compromised, the attacker can get tickets as the user  
anyways, so that doesn't seem like a useful attack scenario.  Perhaps  
a user uses a weak password to get an initial TGT, then uses kinit 
+FAST to get a TGT for some other principal?  It's a clumsily set up  
environment, but may be possible.

But as I described, I think using the host key for FAST also has its  
potential risks.  As does anon-PKINIT in the face of an active  
attacker.  If "secure ID-no-key" is used under FAST-with-host-key, and  
the exchange is recorded and the host key later compromised (but  
within the lifetime of the issued tickets), isn't that unsafe also?

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 May 2009 15:34:13 -0400

>>>>> "Ken" == Ken Raeburn <[email-masked]> writes:
    Ken> an active attacker.  If "secure ID-no-key" is used under
    Ken> FAST-with-host-key, and the exchange is recorded and the host
    Ken> key later compromised (but within the lifetime of the issued
    Ken> tickets), isn't that unsafe also?

Yes.  Although it's likely that if the host key is compromised in this
period, the tickets will also be compromised.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Wed, 27 May 2009 10:31:12 +0530

> Can the attacker force the client to use a weak armor ticket?

[Srinivas Cheruku] Maybe an attacker can change the contents of etypeinfo(2)
to use weak encryption types. For this to occur, the host principal used to
acquire armor ticket should require pre-auth and KDC should respond with
etypeInfo(2) in KRB-ERROR in a non-FAST request. But, if the keytable file
doesn't have weak encryption type then this attack can be void.

> Does the client or the KDC have an incentive to use a weak armor ticket
> rather than leaking part of the armor key?
[Srinivas Cheruku] No.

> session key.  Such a ticket cannot successfully be used as an armor

I was not sure how can a weak armor ticket can be forced when starting this
topic, but I thought it might be good to take others opinions on this.

Thanks,
Srini