[Mono-dev] RFC on remoting security stuff

[Sebastien Pouliot]

On Mon, 2007-10-01 at 17:00 +0900, AtsushiEno wrote:
> Hi,
> 
> As part of filling .NET 2.0 API, I am wondering how and what we need to do
> secure remoting support (introduced in 2.0), namely HttpChannel, TcpChannel
> and IpcChannel. (I'd like to put my disclaimer - am far from familiar
> with those
> remoting stuff, so don't hit me if I am misunderstanding the entire bits ;-)
> 
> It seems that secure remoting stuff sorta involves
> WindowsImpersonationContext
> which is based on authentication information which will be likely from
> System.Net.CredentialCache.DefaultCredentials (if written in managed land).

> DefaultCredentials seems to require CAS (and some work, as it is
> commented as "Need EnvironmentPermission implementation first"). 

I don't see why - as this exists in Windows without .NET. It's probably
a local comment (for the next few lines) and not a global one.

> So I guess
> it is not likely possible to implement security support in the same
> manner as
> .NET does.

The real problem is interoperability. 

Right now the 1.x profile implements some WindowsIdentity stuff so we
use (a) Windows API stuff under Windows and (b) POSIX API elsewhere.
This enabled us to provide similar features using the same managed API.

However in 2.x the API is much larger. Part of it goes deeply into Win32
structures and design (which doesn't map so well with POSIX) while other
parts offers network support.

So for network interop purpose our 1.x stuff isn't correct. We need a
Windows-client, either managed (one can dream ;-) or by integrating with
unmanaged libraries (samba, kerberos...).

> So I'd like to hear you guys' ideas. 

I don't know enough about all channels but it's possible that some, like
HTTP, can be implemented without a Windows-client (e.g. using mostly
HTTP+SSL support). For such "open" channels I think it would be worth
the time to implement them.

> Would we just leave them unimplemented,

IMHO advanced Win32-specific features that does not benefit Mono
(elsewhere) should be considered "out-of-scope" with a big
"contributions welcome" sign over them.

> or find some alternative security support, 

Probably out-of-scope for Mono but someone(s) could build, on open
standard and FOSS, something very similar to the WindowsIdentity and
impersonification features. That would be useful, both to Mono and to
Windows developers that don't like being tied to Windows anymore that
they can avoid.

> like using TLS to at least enable
> encryption (and optionally integrity by some certificate configuration) ?

SSL/TLS offers integrity. Client authentication requires (from a
protocol perspective) x.509 certificates.

> (While we could implement NegotiateStream and hence secure connection itself
> would not be an issue, am having problems to solve NTLM issue on my machine
> and cannot implement it so far.)

Even Negotiate has it's own problem. The identity cannot be created like
it is on Windows (we would need the password). Also this protocol is a
simple "switcher" on the older NTLM and newer PK-enabled Kerberos
available in different versions of Windows (so we need both for
interoperability).

> Atsushi Eno
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list