Fleshing out Security

Abbie -

I took an action item to try to work with you to flesh out the security
section a bit.  There are two issues:

1 - The section details threats but discusses the policies that address
these threats in a general way with some examples.  It would be really
useful to enumerate a list of policies that at least illustrate how each
threat can be addressed.

2 - I personally think that some statements that addressing certain
threats are out of scope for the architecture are incorrect.  I think
that in fact the difficulty is, at least in some cases, a matter of
tradeoffs involved with the technology, not the architecture itself.  As
an illustration, it is claimed that addressing buffer overruns is
inherently in the application domain.  As an illustration that this is
not correct, let me point out that traditional EDI does not, I believe,
have much of a problem with buffer overruns because it uses fixed length
fields in the message formats.  It is the fact that text fields in XML
can have any length that makes the problem possible.  Well, then, what
kind of policy could one imagine that would limit the lengths of fields
in XML?  I think that such a policy can certainly be envisaged, although
I am not quite sure how to articulate it.  Whether one would want to
accept the tradeoffs involved in actually using such a policy is another
question. 

In the hopes that it may be possible to harvest something from it, let
me append here some text that I wrote about Web services security for
internal consumption.  I believe that it approaches the issue from the
"other direction" (that is, the policies or protocols that can be used
to respond to threats), but you will note that at a certain point I more
or less throw up my hands and say, "I don't know enough specifics to go
beyond this level".

  *******************
As soon as you start looking at using Web services across the internet,
particularly in B2B applications, you have to worry about security.
There are seven basic requirements for security:
	1 -Identification - Who are you? 
	2 -Authentication - Prove your identity. 
	3 -Authorization - Are you allowed to do this? 
	4 - Integrity - Are the data you sent the same as the data I
got? 
	5 - Confidentiality - Can anybody else see what we are doing? 
	6 - Auditing - One or both of us keeps a record of what has
happened. 
	7 - Non-Repudiation - Both sender and receiver can prove that
the sender sent the data and the receiver got it. 
At the most basic level, SSL/HTTPS
<http://developer.netscape.com/docs/manuals/security/sslin/contents.htm>
can provide, at the protocol level, 1,2,4 and 5 -- that is,
identification, authentication, integrity and confidentiality. To be
more specific, if one party has a certificate (as would be the case if
you are using HTTPS to input credit card information to an on-line
merchant), you get integrity and confidentiality. Identification and
authentication are added if both parties have certificates, exchange
public key information and agree on some suitable source of trust. This
level of security is adequate for some important uses -- for example
when you are doing business with a trusted business partner using
protocols understood by both parties and back-office systems on both
ends to handle the business logic. It is important, however, to
understand the limitations of this security. 
	1 - There are no mechanisms defined by the protocol for
authorization, auditing or non-repudiation, mainly because ... 
	2 - Services are at the protocol level and do not carry through
into the backend systems. For example, the digital signature does not
easily carry through to the database so that it can be stored for later
use in non-repudiation, audit trails and so on. 
	3 - It works by encrypting everything during transmission and
decrypting it all at the time of delivery. There is no provision within
the protocol for selective or persistent encryption. 
The security protocols offered by WS-Security
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwsse
cur/html/securitywhitepaper.asp>  and ebXML messaging
<http://www.oasis-open.org/committees/documents.php?wg_abbrev=ebxml-msg>
are, in contrast, at the message level, achieved by extensions to the
SOAP headers. This means that digital signatures are available for
archival storage, the message may remain encrypted after transmission,
and mechanisms can be devised to satisfy all seven of the basic security
requirements. The protocols themselves do not contain mechanisms for
audit trails or non-repudiation, but the necessary information for these
functions is there and can be exploited by the back-office system.
This basic level of security is enough to get going with safety in
pretty much all circumstances. There are, however, more granular and
sophisticated security requirements that address issues of security
administration, high volume usage, granular and complex permissions,
data content of special concern and so on. These issues may arise as
business applications become more complex or are used more heavily, and
there are a number of specifications either available or in progress
(e.g. SAML, XACML, XKMS, ID-FF, etc) that address more sophisticated
areas of security. This is definitely an area that requires specialized
expertise, and I am not the person to tell you about these things.