Windows CCAPI design sketch

[Kevin Koch]

http://web.mit.edu/kpkoch/Public/CCAPI-Windows-Design.html has been updated
to reduce the number of endpoints and use the logon session ID in the
endpoint name.  

At the same time, I'd like the benefit of the eight years of learning.
After I read the change logs, I might not fully appreciate some subtlety and
might repeat some mistake.  If Jeff is talking specifically about the naming
of endpoints, then what about lifting that code out of the current
implementation?  Any clarification will be appreciated.

Thanks.

Kevin Koch

-----Original Message-----
From: Jeffrey Altman [mailto:jaltman at secure-endpoints.com] 
Sent: Friday, November 09, 2007 12:31 AM
To: kpkoch at MIT.EDU
Cc: kfwdev at MIT.EDU
Subject: Re: Windows CCAPI design sketch

Kevin Koch wrote:
> I've outlined the main parts of the Windows CCAPI design for your reading
> enjoyment at http://web.mit.edu/kpkoch/Public/CCAPI-Windows-Design.html.
>
> You don't need to point out that these are missing:  authenticating the
> client and server, starting up the server.
>
> Comments are welcome.
Reading through the design, I'm not sure I understand why the reply
cannot be sent back to the requester using the RPC connection
established by the requestor (the client).  Yes, you need to separate
the incoming request thread from the worker thread, and yes, you must be
able to process multiple incoming requests at the same time, and yes,
you must be able to associate the reply with the correct RPC request. 
However, all of this is reasonable to do.  Using the concept of a
separate reply endpoint for each and every thread is going to result in
a lot of additional complexity in the client side implementation.

Your core code is not going to be thread safe.  That just means that you
need to wrap all calls into that code with a CriticalSection so that
only one thread can process in that code at a time.  You must also
ensure that you never block in that code to wait for logical locks
unless you exit the CriticalSection. 

You ask if there are any security issues with the client listening for
requests from the server.  No more so than the security issues of the
server listening to requests from the client.  If you can authenticate
the peer process so that you know you are talking to the correct entity,
there would be no issues.

Maintaining open connections to the "alive" endpoint of the client seems
wasteful.  There is a need for a client side endpoint to be used for
sending change notifications.  This is so that the client doesn't have
to poll the cache server every minute as is done today.  Why can't the
server simply cleanup resources when a change notification fails to
establish a connection to the client endpoint?

Please review the way that RPC endpoints are named in the current CCAPI
implementation.  If you are only using the "USER" name for the server
endpoint, you will have collisions between multiple sessions on a
terminal server implementation.  You will also have problems with the
CCAPI server instances that are created by winlogon.exe.  The endpoint
needs to be bound to the logon session not to the user.   There is a lot
of history in the existing implementation.  Please do not repeat the
mistakes that have been made over the last eight years.

Jeffrey Altman