From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] auth protocol questions + proposed kfs improvement
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20011102070925.DD951199B9@mail.cse.psu.edu>
Date: Fri,  2 Nov 2001 02:09:22 -0500
Topicbox-Message-UUID: 125d28a4-eaca-11e9-9e20-41e7f4b1d025

> 1.  Is there any security reason why /dev/authcheck
> didn't already work with AuthTs flavored tickets and AuthAc
> flavored authenticators?

Yes, /dev/authcheck was only intended to be used
for checking the credentials presented by servers.

> 2.  What is the reason for strcmp(up->user, cp->t.cuid)?
> 3.  Repeating my original question, is there a security reason
> for the distinction between AuthTs and AuthTc flavored tickets,
> and the distinction between AuthAc and AuthAs flavored authenticators?

Both of these might only be paranoia (I'm sure presotto will
say for sure), but paranoia for its own sake isn't a bad thing.  The
distinction makes very explicit which messages are intended to be
used where.

If you don't do this, it's too easy not to be explicit enough.
The Needham and Schroeder protocol is the most commonly cited
example, but here's one closer to home.  If you diff auth(6)
between second and third edition you'll notice a slight change:
the password change ticket sent back from the AS is of type
AuthTp instead of AuthTc.  The reason is that if I could convince
a client host to talk to me instead of the real AS, I could relay all
the traffic through until I get a password change, at which point
I can convince the client host to tell me its password.

	UserProc->FakeAS: AuthPass, xxx, xxx, xxx, xxx, UIDc

	FakeAS->RealAS:   AuthTreq, xxx, UIDfakeas, xxx, UIDc, UIDc
	RealAS->FakeAS:   AuthOK, Kc{AuthTc, ..., Kn} Kfakeas{AuthTs, ..., Kn}

	FakeAS->UserProc: AuthOK, Kc{AuthTc, ..., Kn}
	UserProc->FakeAS: Kn{AuthPass, old password, new password}

The fake AS sends a ticket request, getting a pair of
similarly encrypted tickets with the same nonce key.
It can relay the Kc ticket (which it can't decrypt) to
the client, but then decrypt the Kfakeas ticket to recover
the nonce key, which lets it decrypt the password change
message.

The problem here is that the AuthTc ticket type got used
in two places for different purposes under different assumptions.
I stumbled across this while checking the protocol using
some authentication logics.  The problem with such checks,
of course, is that they don't guarantee to let you find all
the problems.  Maybe if you merged AuthTs and AuthTc and also
AuthAs and AuthAc, everything would work out.  But maybe not,
and that's the argument for being as explicit as possible.

(In this case, I think you could rederive the original type
by looking at the user ids in the message.  But maybe not always.)

Russ