Here is my attempt at a brief description of the Windows 2000 client token security problem and a proposed solution.
Let me start with a scenario of how it works in the simple case (e.g., for Windows NT).
(1) The cache manager starts and registers itself as an SMB server with the name \\<computer name>-afs.
(2) When a user does an AFS logon (through klog or the AFS authentication panel), the AFS token is passed to the cache manager using a pioctl call, which is implemented as an SMB write request to a special filename recognized by the cache manager. The SMB write request is sent within an SMB session. The Windows SMB client sets up the session with the AFS cache manager, during which a user name and a new SMB session Id are presented. By default the user name is the same as the Windows logon name of the user. The cache manager does not perform authentication of the SMB user name and does not ask for an SMB password. It assigns this user a "User Id" which the Windows SMB client will use in sending the token-passing SMB write request and all future requests for the same user. The cache manager associates the received AFS token with the Session and User Id pair. From now on, all SMB requests with this Session & User Id's are serviced using the associated AFS tok! en.
The above scheme is sufficient for Windows NT because it keeps a single SMB session while the users is logged on. However, it is broken on Windows 2000 because Windows spontaneously starts new sessions with connected servers which essentially invalidate established User and Session Id's. User names are sent to the cache manager again in this process and the cache manager (the SMB server) needs to map these users to existing AFS tokens. This was not done in early versions of AFS Windows 2000 client, and users experienced lost tokens.
The current Open AFS approach to this problem maps <user name, machine name> pairs to AFS tokens. When a new AFS token is sent through the token-passing SMB request to the cache manager, the token is tagged with the user name and machine name of the SMB request. Subsequently, when new Session & User Id's are generated when setting up a new SMB session, the <user name, machine name> tuple in the SMB message is used to find the associated AFS token(s) for this new Session & User Id's.
It might sound like the problem is solved. But it is not. This approach has a security hole because Windows SMB client allows a user to choose any user name when connecting to SMB shares, and the cache manager trusts the use of the name to be legitimate without challenging the user. This allows a user to use another's user name to get access to his tokens. Note that this problem does not affect machines that are not shared by multiple users.
PROPOSED SOLUTION:
One possible solution we are experimenting with is to use secret SMB user names that are dynamically generated. Before a user's AFS token is passed to the cache manager the first time, the AFS logon program selects a randomly generated long string as the SMB user name. When the token is passed to the cache manager, this token will be tagged with the secret user name. The user does not need to know what the secret name is and never needs to type it in. There is no reason for the user to change his SMB user name for accessing \\<computer name>-afs. Therefore, in all new sessions or session setups that Windows spontaneously create, the same secret user name and machine name will be used and the correct AFS token(s) will be mapped. Attempts to use other user's tokens will be prevented because there will be no way to know what the dynamically generated names are.
We need to confirm that the SMB client on Windows 2000 will never reveal the list of SMB user names that are in use (at least not to non-privileged users). We think it would be a security exposure of the Windows 2000 OS itself otherwise. Nevertheless we need to know. Suggestions and comments are welcome!
Shyh-Wei Luan
Sent by: [EMAIL PROTECTED]
To: Sam Hartman <[EMAIL PROTECTED]>
cc: James Peterson/Almaden/IBM@IBMUS, [EMAIL PROTECTED], Marc Dionne <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], Shyh-Wei Luan/Almaden/IBM@IBMUS
Subject: Re: [OpenAFS-devel] Multi-User Windows 2000 Token security
On Thu, Sep 27, 2001 at 11:15:06AM -0400, Sam Hartman wrote:
> >>>>> "Leif" == Leif Johansson <[EMAIL PROTECTED]> writes:
>
> Leif> On Wed, Sep 26, 2001 at 05:24:42PM -0700, James Peterson
> Leif> wrote:
> >> As others have mentioned there is a security problem with
> >> Windows 2000 in a multi-user environment.
> >>
> >> The only work around is, for multi-user Windows 2000 configure
> >> it so that all Logon require a restart.
> >>
>
> Leif> If we can trust the security (?) of the local filesystem we
> Leif> could presumably replace klog with kinit+afslog (I am
> Leif> temporarily ignoring the problems of getting a
> Leif> multiuser-safe kerberos on windows) and do and afslog on
> Leif> each smb session start. Would this be possible or have I
> Leif> just assumed someting unrealistic, like access to windows
> Leif> sources... ??
>
> I don't think you need to trust local filesystem. I think you could
> recompile kenh's aklog against a version of MIT Kerberos that supports
> ccapi and have a solution for at least krb5.
I thought the issue was that the session can be split over multiple
smb-sessions which each needs access to the token. If we could force
each smb-session to do the equivalent of an afslog/aklog using a normal
krb5 ccache file we could go back to having a separate token for each
smb-session.
MVH leifj
_______________________________________________
OpenAFS-devel mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-devel
