Subject: Call for objections and alternative proposals

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Dec 2001 14:32:18 -0500 (EST)

Hi.  As you no doubt know having read Doug's draft minutes, we'd like
to move fairly quickly on the revisions document.  This means that we
need to find some proposal that implements the extensibility goals we
seem to have consensus on.

We've presented our proposal to the working group and some people have
raised some specific objections.  We believe we've got solutions to
all those objections and I should be working through the open issues
list this week publishing text that should close them.

However, at least two people raised more general issues about the
proposal at the working group meeting.  This is a formal request that
people with general objections/concerns about the proposal either
present those issues or alternative proposals.  I'd really like to see
such objections/proposals presented by the first week in January.  I
realize that's a short time line, but we want to get these proposals
integrated in time for a February meeting.

I'm not trying to imply that people aren't already busy writing up
their concerns; people have told me in person that they are.  I just
want a formal call for such concerns to be registered in the archive
of the working group so I'm sending this message.

---

From: Jonathan Trostle <[email-masked]>
Date: Tue, 18 Dec 2001 15:35:09 -0800

Sam,

In your Kerb WG presentation, I heard you mention the potential need for
client configuration. Could you explain why/where/when this configuration
is needed?

Jonathan

---

From: Sam Hartman <[email-masked]>
Date: 18 Dec 2001 18:40:54 -0500

>>>>> "Jonathan" == Jonathan Trostle <[email-masked]> writes:

    Jonathan> Sam, In your Kerb WG presentation, I heard you mention
    Jonathan> the potential need for client configuration. Could you
    Jonathan> explain why/where/when this configuration is needed?

First, you'll note that the minutes accurately claim that I said you
could do client configuration and it should be allowed by the proposal
but discouraged.  You can have a client that allows krb5.conf to
specify that only new messages should be used.

If you do this then you'll remove potentially one round trip but
you'll introduce screwy error conditions if the realm ever downgrades
to old KDCs.

In general I'd like to avoid client configuration where possible
because we want to support stateless clients.

However there is one case where you want to configure clients.  If you
want to set up a client policy that krb-error messages must be
authenticated then you must configure your clients to know about this
policy.  This is true for other Kerberos policy decisions as well; if
I want to reject DES-based enctypes because they are weak, I need to
tell my clients to do so.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Dec 2001 19:17:11 -0500

> tell my clients to do so.

Is it not true that there are circumstances where a krb-error cannot be
authenticated at all? E.g., pre-auth failed errors?

Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

---

From: Jonathan Trostle <[email-masked]>
Date: Tue, 18 Dec 2001 17:16:31 -0800

> authenticated then you must configure your clients to know about this

If the KDC and servers support the new message types, wouldn't the client
always expect authenticated error messages? And the client would learn
about
the KDC capability in the initial AS exchange, correct?

Jonathan

---

From: Sam Hartman <[email-masked]>
Date: 19 Dec 2001 16:56:54 -0500

>>>>> "Jonathan" == Jonathan Trostle <[email-masked]> writes:

    Jonathan> If the KDC and servers support the new message types,
    Jonathan> wouldn't the client always expect authenticated error
    Jonathan> messages? And the client would learn about the KDC
    Jonathan> capability in the initial AS exchange, correct?

Assuming no active attack, yes.  If there is an on-going active attack
you can be forced to downgrade to the old protocol.  The only way to
avoid that is to have a policy that forbids the older protocol.

---

From: Jonathan Trostle <[email-masked]>
Date: Wed, 19 Dec 2001 14:44:10 -0800

Sure. So I would state it as you need configuration to always have the new
protocol including the authenticated error messages.

Jonathan

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Dec 2001 17:41:08 -0500

> avoid that is to have a policy that forbids the older protocol.

Well, yes and no.

Clients can be configured to know which realms support new Kerberos, in
which case no such attack is possible, OR

clients discover which realms support new Kerberos and cache that
information for some amount of time, in which case the downgrade attack
may or may not be limited to clients who have no cached or expired cached
realm information.

Also, the downgrade attack is possible only during AS exchanges.

Finally, I don't see how we can secure *every* KRB-ERROR without
resorting to public cryptography. Examples of errors that probably can't
be secured would be: pre-auth required, pre-auth failed, client
principal unknown, etc...

Yes, we could use PA-TGS-REQ as I've suggested before in AS exchanges to
add host-based authentication to the exchange and provide a key of last
resort (and other features I've mentioned). But even then, it's possible
that the host key becomes invalid and so on, so, short of using public
cryptography we can't authenticate every KRB-ERROR.

Nico