Subject: Kerb WG iakerb

From: Martin Rex <[email-masked]>
Date: Wed, 13 Feb 2002 12:39:48 +0100 (MET)

I don't know whether I ever explained why the underlying IAKERB
message exchange makes me uncomfortable (which is why I would
really appreciate if Kerberos Gurus would comment on this part
of the proposal).

(a) requires the KDC to issue a service ticket to a user

(b) requires the Kerberos implementation of the user to cache
    the user's longterm credentials indefinitely

(b)
As far as I understood it was meant to be a feature that the user's
"ticket manager" program (be it kinit or something more sphisticated)
would need to have the user's long term secret only for a very short
time to be able to decrypt the AS_REP response from the KDC, so
that the window of exposure for this longterm key remains as
small as possible.

(a)
Since user's long term secrets are much more vulnerable to dictionary
attacks than the (hopefully randomly generated) long term keys there
is a potential danger in allowing the KDC to issue AP_REQ for
user principals -- because these can be used to mount offline
dictionary attacks.

In order to minimize the possibility for offline dictionary attacks
against user's long term keys the KDC should be permitted to:

* deny issuing service tickets for users (user2user tickets
   are different in that they use a strong random key)

* deny issuing TGTs in absence of valid pre-authentication data

However this would be incompatible with the current IAKERB proposal.

-Martin

---

From: "Jonathan Trostle" <[email-masked]>
Date: Wed, 13 Feb 2002 09:40:22 -0800

----- Original Message -----
From: "Martin Rex" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, February 13, 2002 3:39 AM
Subject: Kerb WG iakerb

>     the user's longterm credentials indefinitely

Sorry, I haven't looked at the draft for quite a while. I vaguely recall
some issue along these lines in an earlier version of the draft but I
thought it was fixed in the latest draft (08). Why would this be required?

> However this would be incompatible with the current IAKERB proposal.

I don't recall IAKERB having these restrictions.

Jonathan

---

From: Martin Rex <[email-masked]>
Date: Wed, 13 Feb 2002 19:40:55 +0100 (MET)

> I don't recall IAKERB having these restrictions.

IAKERB reverses the context establishment between user and IAKERB proxy,
so it requires the KDC to issue a service ticket encrypted in the
user's long term secret.

-Martin

---

From: "Jonathan Trostle" <[email-masked]>
Date: Thu, 14 Feb 2002 00:33:06 -0800

----- Original Message -----
From: "Martin Rex" <[email-masked]>
To: "Jonathan Trostle" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 13, 2002 10:40 AM
Subject: Re: Kerb WG iakerb

> so it requires the KDC to issue a service ticket encrypted in the

The ticket that is targetted at the user is encrypted in the session key
from the ticket that the user sends to the proxy for the TGS case. Same for
the AS case, except the proxy obtains the ticket from the AS exchange. The
fastest way to see this is to look at the diagrams in the spec.

Jonathan

---

From: Martin Rex <[email-masked]>
Date: Thu, 14 Feb 2002 11:27:32 +0100 (MET)

> fastest way to see this is to look at the diagrams in the spec.

You mean that it is a user2user authentication?

No, I didn't see that from the diagrams.  But as I've mentioned
before, I'm not deeply intimate with Kerberos, just with GSS-API. 

-Martin

---

From: "Jonathan Trostle" <[email-masked]>
Date: Tue, 19 Feb 2002 22:50:15 -0800

----- Original Message -----
From: "Martin Rex" <[email-masked]>
To: "Jonathan Trostle" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 14, 2002 2:27 AM
Subject: Re: Kerb WG iakerb

> You mean that it is a user2user authentication?

Right.

Jonathan