RE: D-AG006 Security

> -----Original Message-----
> From: Krishna Sankar [mailto:ksankar@cisco.com]
[snip]
> 	But I do not think non-repudiation is within our domain. It is a
> business artifact and has a lot of legal and business impacts. 

The legal and business impacts can be addressed by digital signature,
which is a wonderful security primitives for WSsec.
Besides, we won't even have to try hard to make this powerful
functionality available in WS-Arch.  XML-dsig is ready for
prime time, not to mention other non-W3C-IETF alternatives.

> For example legally we need to keep records for 7 years and what
> happens if advances in cryptography makes the old way of 
> securing is no more valid ? 

Invalid how?  This is a non-issue as long as private keys are
kept safe.  Public key encryption has been around since the
late 70s, time and proofs done by academics have proven its
worth.  If it's valid enough for the US Congress (which passed
the law circa 1998 legitimizing digital signature as a legal
tender for signing documents, and had deliberated the technology
for years prior to the law's passage), then I see no reason
to lose sleep over the possibility of its obsolescence.
The ciphers or key strength may vary of over time,
e.g. preference of RSA over DH, the increase of key length.
The principle is timeless, in our life time anyway.

BTW, using digital signature to ensure non-repudiation in
transactions is nothing new.  It's been done (in conjunction
with EDI, e.g.) for years.  Ask some brokerage firms and
institutional traders.

> Non-repudiation cannot be solved purely by
> technology/infrastructure. 

We solve the part pertaining to WS-styled electronic transactions.

> 	What is your definition of accessibility ? 

Definition by example (so to leave little room for word bending
like the one we had with WS Def ;-): Transgressions like DOS/DDOS
impair a WS endpoint's accessibility by its legitimate users.
DNS spoofing, matching a valid domain name to a bogus IP address
is another form where the source is the primary targeted victim
(in a transaction), as opposed to DOS/DDOS, where the destination
is the primary targeted victim.


> Would it be covered by AuthZ and privacy ?

No.  See accessibility def above.


> 	I do think privacy is important. Anonymity is part of it, other
> part is not to allow visibility because of a set of
> circumstances/capabilities/side effects; yet another part is 
> the freedom
> to decide how much can be visible under what circumstances. How it
> manifests itself is for us to figure out.

I tend to agree; others, say some advocacy groups, may think otherwise.
Not knowing how privacy crept into the charter, I'd leave it open to
run its own course.  If no one comes forward to champion its cause,
then it may as well fall to way side by default.
(Privacy?  What privacy?)

Cheers,

Joe Hui
Exodus, a Cable & Wireless service
===================================================
> 
> cheers
> 
> 
>  | -----Original Message-----
>  | From: www-ws-arch-request@w3.org 
>  | [mailto:www-ws-arch-request@w3.org] On Behalf Of Joseph Hui
>  | Sent: Friday, March 08, 2002 10:35 AM
>  | To: www-ws-arch@w3.org
>  | Subject: RE: D-AG006 Security
>  | 
>  | 
>  | (My apology to those who might have received this as a 
>  | duplicate to "FW: D-AG006 Security".  I want to maintain the 
>  | "RE:" part in the subject line to preserve the thread's 
>  | lineage.  Joe)
>  | 
>  | > From: Krishna Sankar [mailto:ksankar@cisco.com]
>  | [snip]
>  | > 	I think the requirement is a little too general. I 
>  | would prefer it to 
>  | > be spelled at some point. So summarizing your message, may 
>  | be we could 
>  | > say :
>  | > 
>  | > 	AG006.1 : Address Integrity
>  | > 	AG006.2 : Address confidentiality.
>  | Agreed.  (The two were included in the first msg of the thread.)
>  | 
>  | > 	AG006.3 : Address transfer of context between web services
>  | The transfer of security context?
>  | Can you expand this a bit, preferably with an example?
>  | 
>  | > 	AG006.4 : Address transfer of credentials between web services
>  | I take it that you mean key exchange, such as using 
>  | asymmetric key encryption to exchange symmetric keys.  
>  | Please clarify if you mean something else, or something more 
>  | than that, like the delegation of one Wes's credential to 
> another.  
>  | 
>  | > 	AG006.5 : Address exchange of assertions between web 
>  | services (This 
>  | > is SAML's domain. I think it will be good for us to 
>  | address this at 
>  | > the architecture level)
>  | Can you expand this a bit, preferably with an example?  
>  | Do you mean the WS-Arch should also allow for robust yet 
>  | anonymous transactions, e.g. sellers and buyers don't know 
>  | and don't care who they're doing business with, yet nobody 
>  | gets cheated in transactions? Off cuff, I can only think of 
>  | SAML as a language (from OASIS) for "assertions," which 
>  | allows for anonymity of transacting parties, as opposed to 
>  | "credentials,"  where identities are known and authenticated.  
>  | 
>  | > 	AG006.6 : Address trust models (Everything has a trust 
>  | model - either 
>  | > explicit or implicit. We might as well address this. BTW, 
>  | trust model 
>  | > is what we could influence the most)
>  | Ok.  So I count you in among those who favor including trust 
>  | in security.  I think you're in good company :-)
>  | 
>  | 
>  | Now onto the other.
>  | 
>  | I do not agree with deleting Accessibility.
>  | (Do you care to reason why it should be deleted?)
>  | Someone, sorry I forgot who, said in another thread the 
>  | other day that we should add Accessibility in security to 
>  | the "five security aspects" (Authentication, ..., 
>  | Non-repudiation) I proposed that we should address; and I 
>  | responded by saying we should include it only in the form of 
>  | a Security Consideration.  On second thought, I realize we 
>  | may as well go for broke and do them all, because it can be 
>  | done.  (I can go into the how2 details, but I won't at the 
>  | moment, because the WG's charter has ruled mechanism out of scope.)
>  | 
>  | I do not agree with deleting Authentication.
>  | (Do you care to reason why it should be deleted?)
>  | Most commercial entities won't transact with parties that 
>  | can't be authenticated.  (There's indeed the cybercash 
>  | scenario where transacting parties prefer anonymity.  But 
>  | it's only a corner case.)
>  | 
>  | I do not agree with deleting Authorization.
>  | (Do you care to reason why it should be deleted?)
>  | Most commercial entities only transact with authorized 
>  | parties. WS endpoints should be able to control access to 
>  | their resources, by means of ACL, single-sign-on, licensing, etc.  
>  | 
>  | I do not agree with deleting Non-repudiation.
>  | (Do you care to reason why it should be deleted?) 
>  | Non-repudiation is a very powerful tool for ensuring robust 
>  | transactions.  To that end, people have gone through much 
>  | trouble inventing digital signature and passing laws to 
>  | institute its legitimacy.  We'll be remiss in our WS-Arch 
>  | design if WS providers can't benefit from those achievements.
>  | 
>  | 
>  | > 	AG006.7 : Address Privacy
>  | We need to pin down what Privacy is supposed to mean in our 
>  | WS-Arch first.  Was it tided over from P3P?
>  | 
>  | I'm of the opinion that Privacy should be separate from Security.
>  | 
>  | Mindful of a privacy role in commercial transactions, I've 
>  | tabulated a set of scenarios where "privacy" is synonymous 
>  | with "anonymity," i.e. hiding one's identity from others.  
>  | (Note that hiding one's data/message from other is 
>  | Confidentiality, which we already address in the Security section.)
>  | 
>  | Here's a web service model involving Alice as the provider 
>  | and Bob as the consumer.  Alice is aka "A" to the public and 
>  | "a" to Bob. Bob is aka "B" to the public and "b" to Alice.  
>  | Both Alice and Bob are members of the public.
>  | 
>  | A privacy tabulation:
>  | 
>  |    AaBb: no anonymity (ACLU's nightmare ;-)
>  |          The IDs of Alice and Bob are publicly known.
>  |          Alice and Bob know each other's IDs.
>  | 
>  |    Aaxb: partial anonymity
>  |          Alice's ID is publicly known.
>  |          Bob's ID is not publicly known.
>  |          Alice and Bob know each other's IDs.
>  | 
>  |    xaxb: partial anonymity
>  |          Alice's ID is not publicly known.
>  |          Bob's ID is not publicly known.
>  |          Alice and Bob know each other's IDs.
>  | 
>  |    xaxx: partial anonymity
>  |          Alice's ID is not publicly known.
>  |          Bob's ID is not publicly known.
>  |          Bob's ID is not known to Alice.
>  | 
>  | 
>  |    xxxb: partial anonymity
>  |          Alice's ID is not publicly known.
>  |          Bob's ID is not publicly known.
>  |          Alice's ID is not known to Bob.
>  |          (Buyer doesn't know seller.  Escrow may be needed.)
>  |          Bob's ID is known to Alice.  (Seller knows buyer.)
>  | 
>  |    xxxx: total anonymity (drug dealers' dreams come true ;-)
>  |          Alice's ID is not publicly known.
>  |          Bob's ID is not publicly known.
>  |          Bob's ID is not known to Alice.  (Seller doesn't 
>  | know buyer.)
>  |          Alice's ID is not known to Bob.  (Buyer doesn't 
>  | know seller.)
>  | 
>  | My math says I can make (4**2) sixteen combinations out of 
>  | AaBb. I've only picked out what I think the interesting ones 
>  | in this rough cut.  Please feel free to add.
>  | 
>  | If we're on track with the privacy definition (in our 
>  | WS-Arch context), then we may start picking some from the 
>  | tabulation to throw into a "bucket," so later we can use 
>  | them for requirements.
>  | 
>  | Cheers,
>  | 
>  | Joe Hui
>  | Exodus, a Cable & Wireless service 
>  | ============================================
>  | 
>  | 
>  | 
>  | > 
>  | > cheers
>  | > 
>  | >  | -----Original Message-----
>  | >  | From: www-ws-arch-request@w3.org
>  | >  | [mailto:www-ws-arch-request@w3.org] On Behalf Of Joseph Hui
>  | >  | Sent: Thursday, March 07, 2002 5:40 PM
>  | >  | To: www-ws-arch@w3.org
>  | >  | Subject: D-AG006 Security
>  | >  | 
>  | >  | 
>  | >  | Hi all,
>  | >  | 
>  | >  | As the volunteered "champion" (during today's telecon) for 
>  | >  | one of the WSAWG goals, "AG006 -- addresses the security of 
>  | >  | web services across distributed domains and platforms," I 
>  | >  | wish to solicit your interest in starting and sustaining a 
>  | >  | "spirited" discussion on web services security.  The primary 
>  | >  | objective (of the discussion) is to confirm the stated goal 
>  | >  | by *rough* consensus, and refine it (the goal, not the 
>  | >  | consensus ;-) if necessary.  The secondary objective is to 
>  | >  | harvest the upshot of the discussion and turn it into 
>  | >  | something we can use in near term for identifying "Critical 
>  | >  | Success Factors" -- whatever that may mean to you -- and 
>  | >  | requirements. Hopefully, by being mindful of the objectives, 
>  | >  | we can keep this thread reasonably focused.  However, please 
>  | >  | don't let the objectives adversely constrain your will to 
>  | >  | express.  You're welcome to disregard the objectives and 
>  | >  | throw in whatever you see fit in the spirit of doing good 
>  | >  | for web services security.
>  | >  | 
>  | >  | To get the ball rolling, let me start with the goal 
>  | > statement itself:
>  | >  | 
>  | >  |    AG006 -- addresses the security of web services across
>  | >  |             distributed domains and platforms.
>  | >  | 
>  | >  | Q to all: Is the goal set to your satisfaction?  
>  | >  |           Too broad, too narrow, too ...?
>  | >  | 
>  | >  | Answers/comments?
>  | >  | 
>  | >  | 
>  | >  | To flesh out AG006 a bit more in terms of its implications,
>  | >  | we can give it another whack at what addressing the web 
>  | >  | services security (WSsec) should entail in the architecture 
>  | >  | WS-Arch) to be designed.  Based on some previous discussions 
>  | >  | fragmented across several threads in www-ws-arch@w3.org, an 
>  | >  | assertion can be made that attaining goal AG006 entails 
>  | >  | addressing six security aspects in computing:
>  | >  |    1) Accessibility;
>  | >  |    2) Authentication (of ID and data/messages);
>  | >  |    3) Authorization;
>  | >  |    4) Confidentiality;
>  | >  |    5) (data) Integrity; and
>  | >  |    6) Non-repudiation.
>  | >  | 
>  | >  | Comments?  
>  | >  | 
>  | >  | 
>  | >  | Closely related to security is (the issue of) "trust."
>  | >  | We shall have a security framework alright. The question is: 
>  | >  | should we include trust modeling as a part of the 
>  | >  | framework's design, (e.g.. what trust model(s) to recommend 
>  | >  | or adopt for web 
>  | >  | services,) thus trust is a part of AG006; or should we deem 
>  | >  | "trust" outside the scope of AG006, thus we may need a 
>  | > separate goal?
>  | >  | 
>  | >  | Answers/comments?
>  | >  | 
>  | >  | 
>  | >  | Also, there was the mention of "privacy" in the charter, 
>  | >  | right next to security.  Privacy can mean different things 
>  | >  | in different contexts, ranging from preventing one's home 
>  | >  | address disclosed to a web merchant from being sold to 
>  | >  | junkmailers to keeping one's ID anonymous in transactions. 
>  | >  | I wasn't at the WS workshop last April, so have no clue
>  | >  | what that was about.  Can someone shed some light on what 
>  | >  | the "privacy" is supposed to mean in our WS-Arch context, so 
>  | >  | we can determine whether it will be appropriate to lump it 
>  | >  | into AG006, or set a separate goal for it, or whatever?
>  | >  | 
>  | >  | Answers/comments?
>  | >  | 
>  | >  | 
>  | >  | Please chime in.
>  | >  | 
>  | >  | Thanks,
>  | >  | 
>  | >  | Joe Hui
>  | >  | Exodus, a Cable & Wireless service
>  | >  | 
>  | >  | 
>  | > 
>  | > 
>  | 
>  | 
> 
>

Received on Friday, 8 March 2002 18:33:50 UTC