Microsoft .NET security

[Blair Dillaway]

[Michael]

Test posting. Hello world!


"Blair Dillaway" <blaird@microsoft.com> wrote:
>
>

[Blair Dillaway]

Not certain why the body was lost in my earlier post,
but here's the full text....

Below you will find a copy of an email sent to Jason Harper
in response to his recent article discussing Microsoft .NET
security and privacy features (see
<http://security.devx.com/upload/free/features/zones/
security/articles/2000/11nov00/jh1100-1.asp> ).
I am certain there is fairly broad interest in this topic and
others may find the information below useful.

Regards,
Blair

<--------------------------------------------------->


Jason,

Interesting article and you raise some good issues. There
is a great deal of information already published on .NET
features and functionality relevant to security and privacy.
Obviously, we need to do a better job in communicating
this information since you, and I must assume many
others, seem to be unaware of it. I'm sure you can appreciate
the problems in trying to adequately summarize an initiative
with the scope of Microsoft .NET in the few short papers
you cite as resources. Clearly we did not emphasize our
security and privacy features to the extent you were expecting.

As we release additional .NET products I'm certain you
will see the importance we place on security and privacy
reflected in the features and related product information.
In particular, the .NET Framework contains a rich, and
innovative, collection of security services. I've included a
brief summary of those most relevant to your paper and
additional references below. Most of this information was
initially made public at the Microsoft Professional Developer's
Conference in July of this year. Our first Beta was just released and is
available at http://msdn.microsoft.com/net.

In creating the .NET Framework, we decided it was critical to
address the concerns of both application developers and end
users regarding semi-trusted mobile code and componentized
applications. In particular, it was clear we needed to provide
end-users with an effective mechanism to constrain the behavior
of semi-trusted code. At the same time, we needed to provide
developers with mechanisms to: (1) indicate what authorizations
their code needed to run; and (2) to control sharing of their
components.

This is a complex topic and I won't attempt to provide a
comprehensive answer in this note. Rather, let me briefly
summarize how we've addressed this problem. This glosses
over a number of important details and you should read the
references provided below if interested in how this works.
Our approach relies on an innovative security model which
we refer to as "Evidence-based Security". Evidence, in this
context, refers to attributes about a piece of code. We use
several types of code evidence in our base implementation
to include Zone of origin, Site of origin, Authenticode publisher,and Assembly
Strong Name (a unique, unspoofable, name
supported by Visual Studio 7 and the .NET CLR). This is
extensible by fully trusted code. Evidence is used as input to
the .NET CLR security policy which determines authorizations
for that code. These authorizations are reflected in a
Permission set granted to code. When attempting to access a
protected resource, the permissions of all code in the call chain are checked
to insure they are authorized access. In essence, the behavior of code is
constrained by the least trustworthy component. We refer to this as "Code
Access Security". Developers can optionally mark their code with required
permissions. We won't run this code if policy fails to grant the required
Permissions, saving the developer from writing potentially complex runtime
error handling code to insure graceful failure.

This same model is used to provide a controlled sharing
mechanism for code. In addition to the authorization Permissions
granted to code, we also grant identity Permissions which
reflect trustworthy Evidence. These can be used to limit who
is allowed to call and/or subclass specific classes in code.

Related Materials:
PDC Presentations (see <http://msdn.microsoft.com/events/pdc/>).
A few key presentations include:
An Architectural Overview of the .NET Framework (3-313)
.Net Frameworks Security (3-334)
Security Considerations for Downloaded Controls (1-222)
.NET Framework SDK documentation (B1)
Building .NET Applications - Securing Your Application &
Security Policy Management
.NET Framework Reference - System.Security

ASP.NET provides a rich new approach to building Web
applications and supports dynamic page generation using
server side code as well as Web-accessible objects
(referred to as WebServices). In terms of the issues you raised,
it is important to note that ASP.NET integrates with currently
deployed Web security mechanisms. ASP.NET applications
can take advantage of existing Web-oriented Authentication
mechanisms. Support is included for Basic Auth, SSL
Certificate-based Auth, NT Auth, Forms-based Auth,
Cookie Auth, and Passport Auth. These can be customized in
various ways as described in the SDK. The authenticated
identities can be mapped to Win2000/NT accounts if one
wishes to use the Windows platform access control mechanisms.
Alternately, applications can provide their own authorization
logic based on the authenticated identity.

ASP.NET applications can also take advantage of existing
mechanisms for confidentiality to include use of IPSEC
and SSL.

Related Materials:
PDC Presentations (see <http://msdn.microsoft.com/events/pdc/>).
A few key presentations include:
Active Server Pages+ Security (4-443)
Passport as a .NET Service (3-311)
.NET Framework SDK documentation (B1)
Building .NET Applications - Creating ASP.NET Web
Applications
.NET Framework Reference - System.Web.Security

For applications that have special needs, we support an
object oriented programming interface to cryptographic
services. These include support for proven, industry standard,
algorithms (DSA, RSA, DES, 3DES, SHA1, MD5, ...).
Information on these can be found in the .NET Framework
SDK Reference material under System.Security.Cryptography.
There is also support for the W3C draft standard on XML
Digital Signatures (see System.Security.Cryptography.Xml)
and Microsoft is actively involved in other W3C XML-related
security efforts that will be reflected in future products.
Of course, the Microsoft CryptoAPI services are also still
available for those who prefer a traditional C-API style
of programming.

Naturally, .NET applications hosted on Window 2000 and
Windows NT still have access to the rich authentication,
authorization, and security administration features of those
platforms. Coupled with the features discussed above, we
believe we offer our customers the best platform for building,
deploying, maintaining, and running applications while addressing the critical
concerns for security and privacy.

Be interested in your thoughts once you've had a chance to
review this and the referenced material. If you don't have the
Beta release, you can find on-line documentation at
<http://msdn.microsoft.com/library/default.asp?URL=/
library/dotnet/cpguide/cpguide_start.htm>.

You may also want to subscribe the DOTNET discussion alias
(see <http://discuss.develop.com>).

Regards,
Blair Dillaway
Software Architect, .NET Framework
Microsoft Corp.

CC: dotnet@discuss.develop.com; news.devx.com -
security.internet list