FW: Security requirements

Dear David and Ugo and others,
 
I have a number of comments that I would like to contribute then I will
bow out and let others deicide how to take forward.
 
Firstly we seemed to have dived straight into language implementation
issues.  May I encourage everyone to consider and discuss the merits of
the requirements that I suggested first.  Only if we agree the basic
requirements is it really worth moving onto language implementation (and
a project often starts of with grandiose requirements that can not all
be met or completely met).  So I would ask : do people agree with my
list of proposed requirements or would you like to add, subtract or
re-phrase???
 
To respond specifically to some of David and Ugo's points:
 
1. Where do you stop.
We get to decide that!
I suggested strongly that the way we might met the requirements for
integrity, confidentiality, etc (and yes you could include reliable
messaging as well) would be just to state the requirement at that point
on the choreography description - the what but NOT the how.  Thus
changing hash algorithms, SOAP and so forth are well below the woodwork
as far as we are concerned and do not enter the picture.  I agree and
stated in my initial contribution on this topic that we should not be
concerned about how the declared security requirement is met.
 
2. You lose choreography reuse.
I agree with this point but that does not mean that we should not
provide the ability to state security requirements in the language.  It
is always true that a choreography description that is made too specific
may not be suitable for other purposes, so you are likely to run into
this problem irrespective of security.  What you should be able to do is
craft a choreography description with out any security 'mark up'.  This
becomes your re-usable unit that you can re-use many times over with
varying security mark up.
 
Another point I have already made that I would re-iterate is that a
choreography description will only state requirements on what I think is
called discretionary security.  Any mandatory security will be applied
and enforced below - in the WSDL at the highest and often 'invisibly' to
WSDL, etc in the actual communications stack.
 
David's point about extra states is interesting.  I do not think use of
RM should give rise to any extra.  The complexity is handle by the RM
protocol machine and all the choreography layer need to deal with is
message delivered successfully of message not delivered (for some
reason) and this is the same as for ordinary messaging.  (RM just
increases the probability of success and the probability of failures
being correctly signalled - all useful stuff.)  When you request a
security feature (or several) then, yes, there is the possibility of an
extra type of failure (exception) which the choreography description
designer may choose to handle separately from other failure types.  But
I think here we have crossed into usage matters and perhaps the need for
guidelines, good practice guides and left behind language features.

Best Regards,

Tony                           


 <http://www.choreology.com/>  

Tony Fletcher

Technical Advisor 
Choreology Ltd.
68, Lombard Street, London EC3V 9L J   UK


Phone:  

+44 (0) 870 7390076


Mobile: 

+44 (0) 7801 948219


Fax:    

+44 (0) 870 7390077


Web:

 <http://www.choreology.com/> www.choreology.com


Cohesions(tm)


Business transaction management software for application coordination



Work: tony.fletcher@choreology.com 


Home: amfletcher@iee.org

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com] 
Sent: 20 November 2003 01:15
To: 'Ugo Corda'; Fletcher, Tony; public-ws-chor@w3.org
Subject: RE: Security requirements


OK I want to put a stake in the ground ;)
 
The choroegraphy definition language we develop should NOT defiine ANY
policy information - this includes security.
 
There are two reasons for this:
1. Where do you stop. For example you might need policy information to
cover security standards, digital certificates, reliable messaging
protocol, the version of SOAP, the busines document format, etc to use -
do we really want to think about how we describe ALL of these (as well
as ones I've not thought of) in the CDL? Secondly how do we revamp the
CDL we develop whenever any of the standards on which we are dependent
change?
2. You lose choreography reuse. If a Choreography definition includes
policy information, then, whenever you need to change your policies, for
example a different hashing algorithm in your digital signatures, you
need publish a new choreography definition. This in turn will mean that
you would probably have to reconsider your business process definition
(or orchestration, or ... ) as, unless we are very clever, there would
be no way to know that the only change in the choreography definition
was a policy change and there was no change to the sequence or rules
that define how messsages are exchanged and so the business process
definition did not need to change.
 
So what should we do about policy information and more specifically
security.
 
Firstly, I think the real issue is that the effect of applying a policy
could actually affect how a choreography is performed. For example, from
BurdettML you could have ...
 
<InteractionDef name="SendOrder" fromRole="Buyer" toRole="Seller"
messageFamily="Order">
<InteractionEndStates fromState="OrderSent" toState="OrderReceived"/>
</InteractionDef>

Now if you then included security, then you might have additional states
as in (note the bold) ...
 

<InteractionDef name="SendOrder" fromRole="Buyer" toRole="Seller"
messageFamily="Order">
<InteractionEndStates fromState="OrderSent" toState="OrderReceived,
OrderSecurityFailure"/>
</InteractionDef>


Note that in this the toState would be either OrderReceived or
OrderSecurityFailure.   You could then, in the Choreography definition,
return a different message depending on whether or not there was a
security failure.
 
So the first thing I think we should consider is the allowance of
additional states in a Choreography definition to allow the flow of the
choreography to change depending on the outcome of applying policies
such as security ... or reliable messaging ... although I don't think we
should specify the precise policy information that would be used to
determine whether or not a security failure, for example had occurred.
 
Secondly, I think that, if we do want to include policy information then
it really should be possible to put the policy information into a
separate binding layer, so that the basic choreography - that defines
the sequence and conditions in which messages are exchanged -  can be
reused. This would also mean that if we wanted to support new standards,
new policies, etc then only the binding layer needs to change.
 
Thoughts?
 
David


 -----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
Sent: Wednesday, November 19, 2003 2:06 PM
To: Fletcher, Tony; public-ws-chor@w3.org
Subject: RE: Security requirements


Tony,
 
The WSDL security policies I was referring to are also at the
declarative level (in the WSDL abstract interface). It's only when a
specific binding is defined that those abstract declarations are mapped
to specific information (e.g. SOAP headers) on the wire.
 
Ugo

-----Original Message-----
From: Fletcher, Tony [mailto:Tony.Fletcher@choreology.com]
Sent: Wednesday, November 19, 2003 1:55 PM
To: Ugo Corda; public-ws-chor@w3.org
Subject: RE: Security requirements


Dear Ugo,
 
The idea is not to replicate.  I was hoping I had made that clear at the
beginning by saying that I saw the CDL as being declarative - saying
that things should happen here or there, but not how they happen.  I was
suggesting that one could say that company policy xyz applies at this
point or you could state that this particular message must be made
confidential when sent (for instance).  For this to actually happen when
the message was sent of course the WSDL would have to support that form
of security and something 'under' WSDL (the SOAP engines??) would have
to apply - by encrypting in this case possibly.
 
I hope the intent is clear now.
 

Best Regards,

Tony                           


 <http://www.choreology.com/>  

Tony Fletcher

Technical Advisor 
Choreology Ltd.
68, Lombard Street, London EC3V 9L J   UK


Phone:  

+44 (0) 870 7390076


Mobile: 

+44 (0) 7801 948219


Fax:    

+44 (0) 870 7390077


Web:

 <http://www.choreology.com/> www.choreology.com


Cohesions(tm)


Business transaction management software for application coordination



Work: tony.fletcher@choreology.com 


Home: amfletcher@iee.org

-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
Sent: 19 November 2003 21:37
To: Fletcher, Tony; public-ws-chor@w3.org
Subject: RE: Security requirements


Hi Tony,
 
Assuming that our final CDL will be based on WSDL (which might be an
incorrect assumption, given the fact that we currently have no stable
spec), it's very likely that WSDL 2.0 will contain policy assertions
including security-related ones.
 
Would it still make sense, under that scenario, to replicate those
security policies at the CDL level?
 
Ugo

-----Original Message-----
From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org]On Behalf Of Fletcher, Tony
Sent: Wednesday, November 19, 2003 1:14 PM
To: public-ws-chor@w3.org
Subject: Security requirements


Dear Colleagues,
 
On the teleconference last night I kind of agreed to kick the ball into
play on drafting some security requirements.  So here goes.
 
It seems to me that the CDL can be declarative with regard to security.
In other words it should support notation for flagging that certain
security requirements have to be met at this point but can then rely on
the 'stack' below the Choreography language layer to 'make it so'.
 
It should be possible to flag that a certain policy applies from this
point in the choreography until the choreography ends or another flag is
encountered.
 
Should be able to refer out to standard policy sets or state specific
requirements explicitly.  These should include ability to require:
 
authentication of the partner and or the message content source
 
that a secure audit log is made
 
that a message is protected from change (integrity)
 
that the contents of a message are hidden (confidentiality)
 
that the sending of a message is non-repudiable
 
that the receipt of a message is non-repudiable
 
that the message or message exchange is protected against replay
 
that the time of sending of a message is recorded
 

that the time of receiving of a message is recorded
 
that a time (/date) stamp is attached to a message when sent.
 
I am sure I have missed various things, but I hope that will encourage
others to add / correct / rephrase.
 

Best Regards,

Tony                           


 <http://www.choreology.com/>  

Tony Fletcher

Technical Advisor 
Choreology Ltd.
68, Lombard Street, London EC3V 9L J   UK


Phone:  

+44 (0) 870 7390076


Mobile: 

+44 (0) 7801 948219


Fax:    

+44 (0) 870 7390077


Web:

 <http://www.choreology.com/> www.choreology.com


Cohesions(tm)


Business transaction management software for application coordination



Work: tony.fletcher@choreology.com 


Home: amfletcher@iee.org