At 2:08 AM -0400 8/17/96, Ken Hornstein wrote:
>>I have a token structure that was retrieved using ktc_GetToken, which may
>>or may not contain the uid in the user name (ie. the output of 'tokens' may
>>show afs@cell, or AFS ID XXXX).
>>
>>Is there any reliable way to determine who I am authenticated as from the
>>token?
>
>As you, the user? The answer is "no".
>
>>In case you're wondering, the reason for this is, I am exchanging the token
>>with another host (i.e. remsh style passing using ktc_GetToken and
>>ktc_SetToken).
>
>Just so you know, the rsh token passing that AFS does is really insecure
>(it's vulnerable to network sniffing). So it is probably the _wrong_ thing
>to base a secure service on :-)
No less secure than sending the password in the clear. Considerably more
secure in fact, since the token will have a limited lifetime. But that's
beside the point...
>The way that AFS proves that you are you is that it uses the Kerberos
>ticket that is part of your token (ktc_token->ticket). This contains
>your identity, ticket expiration time, a session key, etc etc, all
>encrypted with the AFS server key (/usr/vice/etc/KeyFile, I think).
>
>When you send this to the AFS server, it decrypts this ticket and uses
>the identity in there to verify that you are you (there is more stuff
>that happens involving the session key, but ignore that for now). Since
>the kaserver and the AFS server are the only ones who know the AFS server
>key (hopefully), the AFS fileserver can be sure that the identity in the
>ticket is correct, since only the kaserver could have generated that ticket,
>and presumably it only did that for someone who proved their identity
>to the kaserver (yes, I know this is an oversimplification).
>This is why a lot of sites are using Kerberos 4 or 5 instead of the AFS
>kaserver - since the TGT stays around, you can use it to get tickets for
>other services instead of AFS, and services like POP only need to know
>their key, instead of the AFS key.
This is not really an option for us... (Not for anyone really who has an
already established user base...) Especially since this would mean having
to change every server, and every station in the cell... Not even remotely
an option.
>However, _if_ you understand the risks involved, you can use an AFS token
>for authentication. Here's a quick outline of the steps that would happen
>during such an authentication:
It'd be considerably easier to just create a huge directory tree,
containing a subdir for every id, and simply try touching a file in the
directory. Rights for each subdir would be writable by the id, but the
owner would not be the id, so they couldn't change the rights.
That, or touch a file in the supposed user's home dir, and check the
ownership afterwards...
---------
I'll have to check and see how the AFS patched 'ssh' does it, cause when it
passes the tokens to the next host, they retain the AFS ID XXXX. Whereas
when using gettoken and settoken, that information is lost.
-- Nathan
------------------------------------------------------------
Nathan Neulinger Univ. of Missouri - Rolla
EMail: [EMAIL PROTECTED] Computing Services
WWW: http://www.umr.edu/~nneul SysAdmin: rollanet.org
