>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 :-)
>The remote host needs to verify who the user is, but all
>that having the token does so far is let it know that the user is
>authenticated to AFS, it doesn't help me to know WHO they are authenticated
>as.
>
>We are using plain vanilla AFS, none of the kerberos srvtab stuff.
>
>The application that we are trying to develop is a authenticated popclient
>that can fetch mail from a POP server without a password. The way it will
>work is, it will pass the token to the remote server, and the remote server
>will verify that the token is valid, and (if it is possible) determine the
>userid from the token and then retrieve that userid's mail. (Essentially
>treating the token as the password.)
>
>Any information about this would be appreciated. Including better ways to
>do what I am trying to do.
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).
For a POP server to verify someone's identity using your AFS ticket, you
would have to tell the POP server the AFS server key. This is definately
a bad idea - if your POP server is co-located with an AFS fileserver, then
it's not a big deal, but otherwise you would have to arrange to have
your AFS server key placed on the POP server every time you changed it.
And remember that if your AFS key get discovered, anyone who knows it
can pretend to be anyone in your AFS cell.
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.
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:
- User generates an authenticator (a message containing the time and an
optional sequence number) and encrypts it with the session key from the
token.
- User sends the authenticator and the ticket (just the ticket, _not_
the whole token) to the POP server.
- The POP server uses the AFS server key to decrypt the ticket, thus finding
out the identity of the person (it's in the ticket) along with the
session key. We can be sure it's really the person who authenticated to
that ticket, for reasons explained above.
- The POP server uses the session key to decrypt the authenticator and
checks the timestampd and optionally a sequence number. If the time is
reasonably close (Kerberos uses 5 minutes) and the sequence number wasn't
used before, then you know this person isn't replaying an old
authenticator.
Again, you'd want to make sure you understood the risks involved with this
approach first.
--Ken
