RE: SOAP header for authentication etc

Satish,

Could you amplify on this somewhat? When you say that
BizTalk and RNIF 2.0 will utilize S/MIME 3 what exactly
do you mean?

Here are some possibilities:

(1) BizTalk and RNIF use mime Multipart/Related packaging,
so, clearly, they can utilize S/MIME for encryption and
digital signing.

(2) You have called out a general security model for BizTalk
(similarly RNIF 2.0). Such a security model may have some
standard XML tags, and these tags specifically support S/MIME 3.

(3) I have missed the point entirely.


- prateek  

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Saturday, September 16, 2000 8:18 PM
> To: 'Krishna Sankar'; Mishra, Prateek; xml-dist-app@w3.org
> Cc: Chippada, Radhika; 'Prasad Yendluri'; 'Vidya Narayanan 
> (Extricity)'
> Subject: RE: SOAP header for authentication etc
> 
> 
> Prateek and Krishna,
> 
> This is belated but perhaps still relevant.
> 
> Prasad and Vidya should be able to provide authoritative 
> information about
> RNIF 2.0 security features.  
> 
> The final version of BizTalk Framework 2.0 (due out in about 
> a month) will
> have message-level security features centered on S/MIME 3 (in 
> common with
> RNIF 2.0 to the best of my knowledge).
> 
> Satish
> 
> -----Original Message-----
> From: Krishna Sankar [mailto:ksankar@cisco.com]
> Sent: Wednesday, July 05, 2000 7:57 PM
> To: Mishra, Prateek; xml-dist-app@w3.org
> Cc: Chippada, Radhika
> Subject: RE: SOAP header for authentication etc
> 
> 
> Hi,
> 
> 	Thanks for the detailed message, of course, Netegrity 
> is famous for
> your
> security implementations.
> 
> 	As you have mentioned, it is useful to learn from and work with
> existing
> standards, especially in case of Rosettanet. IMHO, BizTalk 
> has a lot of
> synergy with RosettaNet - more synergy than commonality, 
> which is good.
> 
> 	1.	As you had mentioned, certificates and SSL 
> (client+server
> authentication) transport gives RosettaNet wire level security.
> 	2.	And we can use the identity from the 
> certificate for authC
> and authZ.
> 	3.	I am not happy with the current repudiation 
> method,  as it
> is the
> responsibility of the sender/receiver to store the messages plus some
> non-repudiable timestamp - which requires some good time service.(The
> sender/receiver also need to store the CRLs). I would rather see this
> happening at the infrastructure/framework level like from a BizTalk
> implementation (plus some third party time servers providing the
> non-repudiable time service)
> 	4.	Rosettanet does have digital signature for 
> integrity which
> we could
> model after for BizTalk. They use the detached signature approach.
> 	5.	Rosettanet does not have encryption which I 
> think it plans
> to rectify in
> ver 2.0.
> 	6.	I do not know what other security aspects are 
> forthcoming in
> the
> RosettaNet 2.0 version.
> 
> 	cheers
> 
> 
> -----Original Message-----
> From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> Sent: Wednesday, July 05, 2000 11:25 AM
> To: 'Krishna Sankar'; 'xml-dist-app@w3.org'
> Cc: Chippada, Radhika
> Subject: RE: SOAP header for authentication etc
> 
> 
> Hi Krishna,
> 
> You mentioned RosettaNet which is a good example
> of an existing B2B framework. It might be useful
> to analyze the existing security framework in RosettaNet
> in regards to security (Authentication, Authorization).
> 
> My understanding is that RosettaNet primarily uses
> transport-level security secured by HTTPS + Client certificates
> for Authentication. The subject common name is used
> to figure out the identity of the individual or service
> pushing the document (transport identity).
> 
> Authorization is derived from transport
> identity and Activity Name. Roughly speaking, this translates
> to: Is this identity authorized to carry out this activity?
> 
> PIPs also specify Non-repudiation of receipt and Origin
> and Content. In RosettaNet, this simply means that the
> sender or receiver agree to store the receipt or original
> document for an agreed upon period of time in its original form.
> 
> Additional security is available thru Business Data Entity
> Security. This basically means that individual data items can
> be encrypted, included in a message digest and digitally signed.
> 
> Is that a complete list of security features within RosettaNet?
> How far do we need to go beyond this list in XML Message Exchange
> frameworks?
> 
> - prateek mishra
> 
> Netegrity, Inc.
> Waltham, MA
> 
> 
> > -----Original Message-----
> > From: Krishna Sankar [mailto:ksankar@cisco.com]
> > Sent: Tuesday, July 04, 2000 2:27 PM
> > To: xml-dist-app@w3.org
> > Subject: Re: SOAP header for authentication etc
> >
> >
> > Hi,
> >
> > 	Saw your posting. Yes, we need support for security.
> > Building in security
> > related stuff in the SOAP specification will add
> > interoperability. This is
> > more important now, because BizTalk is based on SOAP.
> >
> > 	As you know BizTalk is agnostic to Temporal and spatial
> > requirements plus
> > it is distributed across organizations. So we need security
> > mechanisms as we
> > do not know where the documents will travel thru and reside,
> > ques, mail
> > slots, ftp sites et al. I really wouldn't trust an open PO
> > thru the BizTalk
> > framework as it stand now (agreed it is only a draft)
> >
> > 	I would like to see the following security related
> > features(and an ready to
> > offer help. We should be able to sit together and figure out common
> > requirements)
> >
> > 	1.	Authentication (not only between servers and
> > clients but between
> > applications)
> > 	2.	I am also a fan of Role Based Authorizations
> > and would like to see if we
> > can extend that concept.
> > 	3.	Support for confidentiality, Integrity and
> > repudiation - Signatures,
> > certificates, time services et al
> >
> >
> > 	FYI, I come from the B2B world (RosettaNet et al) and
> > so wouldn't mind
> > seeing these at BizTalk level. What do you think ? What we do
> > not want is
> > two signatures and two encryptions - one at BizTalk level and
> > another at
> > SOAP level.
> >
> > 	cheers
> >
>

Received on Wednesday, 20 September 2000 15:13:36 UTC