>>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...
That is true; however, one of the points of using Kerberos is that you
don't _have_ send your password in the clear.
>>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.
Since we are starting to do this at our site, I would tend to disagree
with you :-) It's certainly a lot of work, but there's definately a way
to make it a gradual upgrade so you don't have to do everything at once.
>>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...
Eeeeeuuuwww :-) That would certainly work, but it would be a hellish
hack. If you _did_ use that scheme, however, there is one drawback that
I can see. Even if you call ktc_ForgetAllTokens(), the structure that
holds your token stays around for a while afterwards (2 hours). If you
have a lot of people in your cell retrieving their mail via this method,
the structures tend to take up a lot of kernel memory over time and
cause really slow lookups (the hash table inside the kernel isn't that
big). I don't have any numbers on this, but I have seen other people
report problems with similar things in the past.
>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.
The information is definately returned by ktc_GetToken() (it's in
clientName.name, the 4th argument passed to ktc_GetToken); the token-passing
rsh doesn't send it (it also doesn't send the cell name, which makes it
impossible to use AFS rsh across cells, dambit).
--Ken
