You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by George I Matkovits <ma...@uswest.net> on 2000/12/08 04:45:35 UTC
Re: Secure Soap V2A with extended SSL, authentication and (limited)
encryptionsupport
I can not do anything else but hold since the latest CVS tree from 12/6 does
not seem to work correctly for me. Thank you for your comments, I fully agree
with the 'review' process and I will attempt to defend the proposed solution
here later. Unfortunately, here and everywhere, any and all of the current
solutions are based on a PKI infrastructure which mandates the use of the very
inefficient Public/Private Key technology which is around 1000 times less
efficient then traditional symmetric keys like tripleDES (DEsade) What would
this mean for performance? If the overhead of symmetric key encryption on a
UDDI Server is 10% then you would need additional 100 CPU's (YES additional
ONE HUNDRED CPUs! :-) to get equivalent performance. This kind of performance
is NOT acceptable in a commercial environment. While the cryptographic
characteristics of the PKI environment are well understood its performance
implications are NOT, due to the so called Security Community's heavy
commercial involvement. I am happy that we started the discussion about PKI's
commercial promise as far as its 'performance' issues go. Any sane person (one
who can count on his/her own fingers :-) will understand that the
Publiv/Private keys can only be used for a session key definition which
unfortunately does not work for 'routed' XML documents (someone from IBM
pointed this out when I first posted the current SSL mods to Soap) between
UDDI Processing Stations.
I hope someone will have the best of both worlds ASAP because we need it NOW.
SSL does not stop someone from connecting to an UDDI server and deploying a
'malicious Trojan' Java program. Only secure one-per-user (encrypted?)
passwords and an automated methodology for generating the Server's ACL could
provide the foundation for that.
Thank you again for your comments. I will post another update as soon as the
code in the CVS tree works again, currently sequential applications die
eventually with an 'Connection aborted by peer: JVM_recv in socket input
stream.' IMHO the problem is with both Servlets new context management code.
Someone from IBM made the last commit. Could you please use your influence
within IBM to either undo it or fix the problem (The next, more comprehensive
version of SecureSoap, works only against the 9-18 CVS tree :-).
Regards - George
Darrel Drake wrote:
> George,
>
> I was able to more thoroughly review the design points of SecureSoap 2A
> over the weekend (my Monday), especially as it related to digital signature
> and encryption -- as I was not so familiar with this aspect. So I'd like to
> elaborate on the concerns that I voiced last week.
>
> Client side SSL support for Apache SOAP is a definite need. We all hope
> that people will use SOAP for real B2B applications, and this development
> is a step toward SOAP's maturity in that sense. In addition to the
> transport level confidentiality and integrity that are provided by SSL,
> SOAP-level security is necessary. However, we may want to consider a
> different approach than you are currently proposing (at that level).
>
> When it comes to XML security, I believe we should take advantage of the
> current W3C/IETF discussion on XML Signature and XML Encryption as much as
> possible. Please see the SOAP signature implementation in IBM's Web
> Services Toolkit (http://www.alphaworks.ibm.com/tech/webservicestoolkit)
> for our current progress on this issue. Also see
> http://www.trl.ibm.co.jp/projects/xml/soap/ for related discussions. Since
> there is no way to mathematically prove the security of a protocol, the
> only way to achieve a reasonable level of security is thorough review by
> security experts. Thus, using existing standards will greatly reduce the
> risk of introducing additional security vulnerabilities.
>
> My view, simply put, is that SOAP should leverage existing technologies,
> not create new ones. Especially in security, since many people believe that
> designing a security protocol that is in fact secure is very difficult.
> Your efforts to improve SOAP security are greatly appreciated by the SOAP
> user and developer communities. But considering the concerns put forward
> above, could you hold committing the code beyond beyond the client side SSL
> support?
>
> Darrell Drake*
> IBM Japan, TRL
> +81-46-215-4175
> EB92401@jp.ibm.com
> * - Notes ID has a misspelling of my name
>
> From: "George I Matkovits" <ma...@uswest.net> on 2000-11-29 20:56
>
> Please respond to soap-dev@xml.apache.org
>
> To: soap-dev@xml.apache.org, matkovitsg@uswest.net,
> sanjiva@watson.ibm.com, cnelson@synchrony.net
> cc:
> Subject: Secure Soap V2A with extended SSL, authentication and (limited)
> encryption support.
>
> Please find attached the latest version of the SecureSoap work. This
> version is
> based on the ApacheSoap2_0 CVS tree from 9-18-2K. It supports:
> 1.) fully configurable SSL transport.
> 2.) UDDI compliant Encrypted Password, signed Distinguished Name
> Authentication
> Header.
> 3.) Diffie-Hellman based triple DESade symmetric encryption environment.
> (Symmetric encryption is around 1000 times more efficient then a PKI based
> one).
>
> 4. Scripts are provided for both Windows and Linux to build the Encryption
> Keys
> and the Server ACL.
> 5. ALL features are configurable by information within Soap.configuration
> files.
Re: Secure Soap V2A with extended SSL, authentication and (limited)
encryptionsupport
Posted by George I Matkovits <ma...@uswest.net>.
IMHO I do understand, I would NOT dream of COMMITTing this without your approval.
I very much appreciate the issues around Security. I posted this for community
review and also because I promised it earlier, SSL is not safe without
one-per-client password protection and the corresponding Server ACL. The other
features are just 'components' for any future work. As far as the SSL code goes I
have both versions working now (no reflection) (Soap.properties file selectable).
Both versions have, unfortunately, problems which Sun can only solve. I will try
to work with them on the relevant forums.
Regards - George
Sanjiva Weerawarana wrote:
> Hi George,
>
> I don't think we're quite communicating yet .. :-)
>
> Please don't commit any of this to the CVS tree even when you do get
> it working. When a committer puts a -1 then that's gotta be removed
> before going ahead (or that's my understanding - Sam please correct
> me if I'm wrong).
>
> Other committers: if you're also against putting in George's server
> side SSL mods please -1 it. IMO it will have a serious negative
> impact on Apache SOAP.
>
> I am 200% in favor of client-side SSL support as that's all that's
> really needed right now (IMO anyway).
>
> Sanjiva.
>
> ----- Original Message -----
> From: "George I Matkovits" <ma...@uswest.net>
> To: <so...@xml.apache.org>; <ge...@lawson.com>;
> <le...@lawson.com>
> Sent: Thursday, December 07, 2000 10:45 PM
> Subject: Re: Secure Soap V2A with extended SSL, authentication and (limited)
> encryptionsupport
>
> > I can not do anything else but hold since the latest CVS tree from 12/6 does
> > not seem to work correctly for me. Thank you for your comments, I fully
> agree
> > with the 'review' process and I will attempt to defend the proposed solution
> > here later. Unfortunately, here and everywhere, any and all of the current
> > solutions are based on a PKI infrastructure which mandates the use of the
> very
> > inefficient Public/Private Key technology which is around 1000 times less
> > efficient then traditional symmetric keys like tripleDES (DEsade) What would
> > this mean for performance? If the overhead of symmetric key encryption on a
> > UDDI Server is 10% then you would need additional 100 CPU's (YES additional
> > ONE HUNDRED CPUs! :-) to get equivalent performance. This kind of
> performance
> > is NOT acceptable in a commercial environment. While the cryptographic
> > characteristics of the PKI environment are well understood its performance
> > implications are NOT, due to the so called Security Community's heavy
> > commercial involvement. I am happy that we started the discussion about
> PKI's
> > commercial promise as far as its 'performance' issues go. Any sane person
> (one
> > who can count on his/her own fingers :-) will understand that the
> > Publiv/Private keys can only be used for a session key definition which
> > unfortunately does not work for 'routed' XML documents (someone from IBM
> > pointed this out when I first posted the current SSL mods to Soap) between
> > UDDI Processing Stations.
> > I hope someone will have the best of both worlds ASAP because we need it
> NOW.
> > SSL does not stop someone from connecting to an UDDI server and deploying a
> > 'malicious Trojan' Java program. Only secure one-per-user (encrypted?)
> > passwords and an automated methodology for generating the Server's ACL could
> > provide the foundation for that.
> > Thank you again for your comments. I will post another update as soon as the
> > code in the CVS tree works again, currently sequential applications die
> > eventually with an 'Connection aborted by peer: JVM_recv in socket input
> > stream.' IMHO the problem is with both Servlets new context management code.
> > Someone from IBM made the last commit. Could you please use your influence
> > within IBM to either undo it or fix the problem (The next, more
> comprehensive
> > version of SecureSoap, works only against the 9-18 CVS tree :-).
> > Regards - George
> >
> > Darrel Drake wrote:
> >
> > > George,
> > >
> > > I was able to more thoroughly review the design points of SecureSoap 2A
> > > over the weekend (my Monday), especially as it related to digital
> signature
> > > and encryption -- as I was not so familiar with this aspect. So I'd like
> to
> > > elaborate on the concerns that I voiced last week.
> > >
> > > Client side SSL support for Apache SOAP is a definite need. We all hope
> > > that people will use SOAP for real B2B applications, and this development
> > > is a step toward SOAP's maturity in that sense. In addition to the
> > > transport level confidentiality and integrity that are provided by SSL,
> > > SOAP-level security is necessary. However, we may want to consider a
> > > different approach than you are currently proposing (at that level).
> > >
> > > When it comes to XML security, I believe we should take advantage of the
> > > current W3C/IETF discussion on XML Signature and XML Encryption as much as
> > > possible. Please see the SOAP signature implementation in IBM's Web
> > > Services Toolkit (http://www.alphaworks.ibm.com/tech/webservicestoolkit)
> > > for our current progress on this issue. Also see
> > > http://www.trl.ibm.co.jp/projects/xml/soap/ for related discussions. Since
> > > there is no way to mathematically prove the security of a protocol, the
> > > only way to achieve a reasonable level of security is thorough review by
> > > security experts. Thus, using existing standards will greatly reduce the
> > > risk of introducing additional security vulnerabilities.
> > >
> > > My view, simply put, is that SOAP should leverage existing technologies,
> > > not create new ones. Especially in security, since many people believe
> that
> > > designing a security protocol that is in fact secure is very difficult.
> > > Your efforts to improve SOAP security are greatly appreciated by the SOAP
> > > user and developer communities. But considering the concerns put forward
> > > above, could you hold committing the code beyond beyond the client side
> SSL
> > > support?
> > >
> > > Darrell Drake*
> > > IBM Japan, TRL
> > > +81-46-215-4175
> > > EB92401@jp.ibm.com
> > > * - Notes ID has a misspelling of my name
> > >
> > > From: "George I Matkovits" <ma...@uswest.net> on 2000-11-29 20:56
> > >
> > > Please respond to soap-dev@xml.apache.org
> > >
> > > To: soap-dev@xml.apache.org, matkovitsg@uswest.net,
> > > sanjiva@watson.ibm.com, cnelson@synchrony.net
> > > cc:
> > > Subject: Secure Soap V2A with extended SSL, authentication and (limited)
> > > encryption support.
> > >
> > > Please find attached the latest version of the SecureSoap work. This
> > > version is
> > > based on the ApacheSoap2_0 CVS tree from 9-18-2K. It supports:
> > > 1.) fully configurable SSL transport.
> > > 2.) UDDI compliant Encrypted Password, signed Distinguished Name
> > > Authentication
> > > Header.
> > > 3.) Diffie-Hellman based triple DESade symmetric encryption environment.
> > > (Symmetric encryption is around 1000 times more efficient then a PKI based
> > > one).
> > >
> > > 4. Scripts are provided for both Windows and Linux to build the
> Encryption
> > > Keys
> > > and the Server ACL.
> > > 5. ALL features are configurable by information within Soap.configuration
> > > files.
> >
Re: Secure Soap V2A with extended SSL, authentication and (limited)
encryptionsupport
Posted by George I Matkovits <ma...@uswest.net>.
IMHO I do understand, I would NOT dream of COMMITTing this without your approval.
I very much appreciate the issues around Security. I posted this for community
review and also because I promised it earlier, SSL is not safe without
one-per-client password protection and the corresponding Server ACL. The other
features are just 'components' for any future work. As far as the SSL code goes I
have both versions working now (no reflection) (Soap.properties file selectable).
Both versions have, unfortunately, problems which Sun can only solve. I will try
to work with them on the relevant forums.
Regards - George
Sanjiva Weerawarana wrote:
> Hi George,
>
> I don't think we're quite communicating yet .. :-)
>
> Please don't commit any of this to the CVS tree even when you do get
> it working. When a committer puts a -1 then that's gotta be removed
> before going ahead (or that's my understanding - Sam please correct
> me if I'm wrong).
>
> Other committers: if you're also against putting in George's server
> side SSL mods please -1 it. IMO it will have a serious negative
> impact on Apache SOAP.
>
> I am 200% in favor of client-side SSL support as that's all that's
> really needed right now (IMO anyway).
>
> Sanjiva.
>
> ----- Original Message -----
> From: "George I Matkovits" <ma...@uswest.net>
> To: <so...@xml.apache.org>; <ge...@lawson.com>;
> <le...@lawson.com>
> Sent: Thursday, December 07, 2000 10:45 PM
> Subject: Re: Secure Soap V2A with extended SSL, authentication and (limited)
> encryptionsupport
>
> > I can not do anything else but hold since the latest CVS tree from 12/6 does
> > not seem to work correctly for me. Thank you for your comments, I fully
> agree
> > with the 'review' process and I will attempt to defend the proposed solution
> > here later. Unfortunately, here and everywhere, any and all of the current
> > solutions are based on a PKI infrastructure which mandates the use of the
> very
> > inefficient Public/Private Key technology which is around 1000 times less
> > efficient then traditional symmetric keys like tripleDES (DEsade) What would
> > this mean for performance? If the overhead of symmetric key encryption on a
> > UDDI Server is 10% then you would need additional 100 CPU's (YES additional
> > ONE HUNDRED CPUs! :-) to get equivalent performance. This kind of
> performance
> > is NOT acceptable in a commercial environment. While the cryptographic
> > characteristics of the PKI environment are well understood its performance
> > implications are NOT, due to the so called Security Community's heavy
> > commercial involvement. I am happy that we started the discussion about
> PKI's
> > commercial promise as far as its 'performance' issues go. Any sane person
> (one
> > who can count on his/her own fingers :-) will understand that the
> > Publiv/Private keys can only be used for a session key definition which
> > unfortunately does not work for 'routed' XML documents (someone from IBM
> > pointed this out when I first posted the current SSL mods to Soap) between
> > UDDI Processing Stations.
> > I hope someone will have the best of both worlds ASAP because we need it
> NOW.
> > SSL does not stop someone from connecting to an UDDI server and deploying a
> > 'malicious Trojan' Java program. Only secure one-per-user (encrypted?)
> > passwords and an automated methodology for generating the Server's ACL could
> > provide the foundation for that.
> > Thank you again for your comments. I will post another update as soon as the
> > code in the CVS tree works again, currently sequential applications die
> > eventually with an 'Connection aborted by peer: JVM_recv in socket input
> > stream.' IMHO the problem is with both Servlets new context management code.
> > Someone from IBM made the last commit. Could you please use your influence
> > within IBM to either undo it or fix the problem (The next, more
> comprehensive
> > version of SecureSoap, works only against the 9-18 CVS tree :-).
> > Regards - George
> >
> > Darrel Drake wrote:
> >
> > > George,
> > >
> > > I was able to more thoroughly review the design points of SecureSoap 2A
> > > over the weekend (my Monday), especially as it related to digital
> signature
> > > and encryption -- as I was not so familiar with this aspect. So I'd like
> to
> > > elaborate on the concerns that I voiced last week.
> > >
> > > Client side SSL support for Apache SOAP is a definite need. We all hope
> > > that people will use SOAP for real B2B applications, and this development
> > > is a step toward SOAP's maturity in that sense. In addition to the
> > > transport level confidentiality and integrity that are provided by SSL,
> > > SOAP-level security is necessary. However, we may want to consider a
> > > different approach than you are currently proposing (at that level).
> > >
> > > When it comes to XML security, I believe we should take advantage of the
> > > current W3C/IETF discussion on XML Signature and XML Encryption as much as
> > > possible. Please see the SOAP signature implementation in IBM's Web
> > > Services Toolkit (http://www.alphaworks.ibm.com/tech/webservicestoolkit)
> > > for our current progress on this issue. Also see
> > > http://www.trl.ibm.co.jp/projects/xml/soap/ for related discussions. Since
> > > there is no way to mathematically prove the security of a protocol, the
> > > only way to achieve a reasonable level of security is thorough review by
> > > security experts. Thus, using existing standards will greatly reduce the
> > > risk of introducing additional security vulnerabilities.
> > >
> > > My view, simply put, is that SOAP should leverage existing technologies,
> > > not create new ones. Especially in security, since many people believe
> that
> > > designing a security protocol that is in fact secure is very difficult.
> > > Your efforts to improve SOAP security are greatly appreciated by the SOAP
> > > user and developer communities. But considering the concerns put forward
> > > above, could you hold committing the code beyond beyond the client side
> SSL
> > > support?
> > >
> > > Darrell Drake*
> > > IBM Japan, TRL
> > > +81-46-215-4175
> > > EB92401@jp.ibm.com
> > > * - Notes ID has a misspelling of my name
> > >
> > > From: "George I Matkovits" <ma...@uswest.net> on 2000-11-29 20:56
> > >
> > > Please respond to soap-dev@xml.apache.org
> > >
> > > To: soap-dev@xml.apache.org, matkovitsg@uswest.net,
> > > sanjiva@watson.ibm.com, cnelson@synchrony.net
> > > cc:
> > > Subject: Secure Soap V2A with extended SSL, authentication and (limited)
> > > encryption support.
> > >
> > > Please find attached the latest version of the SecureSoap work. This
> > > version is
> > > based on the ApacheSoap2_0 CVS tree from 9-18-2K. It supports:
> > > 1.) fully configurable SSL transport.
> > > 2.) UDDI compliant Encrypted Password, signed Distinguished Name
> > > Authentication
> > > Header.
> > > 3.) Diffie-Hellman based triple DESade symmetric encryption environment.
> > > (Symmetric encryption is around 1000 times more efficient then a PKI based
> > > one).
> > >
> > > 4. Scripts are provided for both Windows and Linux to build the
> Encryption
> > > Keys
> > > and the Server ACL.
> > > 5. ALL features are configurable by information within Soap.configuration
> > > files.
> >
Re: Secure Soap V2A with extended SSL, authentication and (limited) encryptionsupport
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Hi George,
I don't think we're quite communicating yet .. :-)
Please don't commit any of this to the CVS tree even when you do get
it working. When a committer puts a -1 then that's gotta be removed
before going ahead (or that's my understanding - Sam please correct
me if I'm wrong).
Other committers: if you're also against putting in George's server
side SSL mods please -1 it. IMO it will have a serious negative
impact on Apache SOAP.
I am 200% in favor of client-side SSL support as that's all that's
really needed right now (IMO anyway).
Sanjiva.
----- Original Message -----
From: "George I Matkovits" <ma...@uswest.net>
To: <so...@xml.apache.org>; <ge...@lawson.com>;
<le...@lawson.com>
Sent: Thursday, December 07, 2000 10:45 PM
Subject: Re: Secure Soap V2A with extended SSL, authentication and (limited)
encryptionsupport
> I can not do anything else but hold since the latest CVS tree from 12/6 does
> not seem to work correctly for me. Thank you for your comments, I fully
agree
> with the 'review' process and I will attempt to defend the proposed solution
> here later. Unfortunately, here and everywhere, any and all of the current
> solutions are based on a PKI infrastructure which mandates the use of the
very
> inefficient Public/Private Key technology which is around 1000 times less
> efficient then traditional symmetric keys like tripleDES (DEsade) What would
> this mean for performance? If the overhead of symmetric key encryption on a
> UDDI Server is 10% then you would need additional 100 CPU's (YES additional
> ONE HUNDRED CPUs! :-) to get equivalent performance. This kind of
performance
> is NOT acceptable in a commercial environment. While the cryptographic
> characteristics of the PKI environment are well understood its performance
> implications are NOT, due to the so called Security Community's heavy
> commercial involvement. I am happy that we started the discussion about
PKI's
> commercial promise as far as its 'performance' issues go. Any sane person
(one
> who can count on his/her own fingers :-) will understand that the
> Publiv/Private keys can only be used for a session key definition which
> unfortunately does not work for 'routed' XML documents (someone from IBM
> pointed this out when I first posted the current SSL mods to Soap) between
> UDDI Processing Stations.
> I hope someone will have the best of both worlds ASAP because we need it
NOW.
> SSL does not stop someone from connecting to an UDDI server and deploying a
> 'malicious Trojan' Java program. Only secure one-per-user (encrypted?)
> passwords and an automated methodology for generating the Server's ACL could
> provide the foundation for that.
> Thank you again for your comments. I will post another update as soon as the
> code in the CVS tree works again, currently sequential applications die
> eventually with an 'Connection aborted by peer: JVM_recv in socket input
> stream.' IMHO the problem is with both Servlets new context management code.
> Someone from IBM made the last commit. Could you please use your influence
> within IBM to either undo it or fix the problem (The next, more
comprehensive
> version of SecureSoap, works only against the 9-18 CVS tree :-).
> Regards - George
>
> Darrel Drake wrote:
>
> > George,
> >
> > I was able to more thoroughly review the design points of SecureSoap 2A
> > over the weekend (my Monday), especially as it related to digital
signature
> > and encryption -- as I was not so familiar with this aspect. So I'd like
to
> > elaborate on the concerns that I voiced last week.
> >
> > Client side SSL support for Apache SOAP is a definite need. We all hope
> > that people will use SOAP for real B2B applications, and this development
> > is a step toward SOAP's maturity in that sense. In addition to the
> > transport level confidentiality and integrity that are provided by SSL,
> > SOAP-level security is necessary. However, we may want to consider a
> > different approach than you are currently proposing (at that level).
> >
> > When it comes to XML security, I believe we should take advantage of the
> > current W3C/IETF discussion on XML Signature and XML Encryption as much as
> > possible. Please see the SOAP signature implementation in IBM's Web
> > Services Toolkit (http://www.alphaworks.ibm.com/tech/webservicestoolkit)
> > for our current progress on this issue. Also see
> > http://www.trl.ibm.co.jp/projects/xml/soap/ for related discussions. Since
> > there is no way to mathematically prove the security of a protocol, the
> > only way to achieve a reasonable level of security is thorough review by
> > security experts. Thus, using existing standards will greatly reduce the
> > risk of introducing additional security vulnerabilities.
> >
> > My view, simply put, is that SOAP should leverage existing technologies,
> > not create new ones. Especially in security, since many people believe
that
> > designing a security protocol that is in fact secure is very difficult.
> > Your efforts to improve SOAP security are greatly appreciated by the SOAP
> > user and developer communities. But considering the concerns put forward
> > above, could you hold committing the code beyond beyond the client side
SSL
> > support?
> >
> > Darrell Drake*
> > IBM Japan, TRL
> > +81-46-215-4175
> > EB92401@jp.ibm.com
> > * - Notes ID has a misspelling of my name
> >
> > From: "George I Matkovits" <ma...@uswest.net> on 2000-11-29 20:56
> >
> > Please respond to soap-dev@xml.apache.org
> >
> > To: soap-dev@xml.apache.org, matkovitsg@uswest.net,
> > sanjiva@watson.ibm.com, cnelson@synchrony.net
> > cc:
> > Subject: Secure Soap V2A with extended SSL, authentication and (limited)
> > encryption support.
> >
> > Please find attached the latest version of the SecureSoap work. This
> > version is
> > based on the ApacheSoap2_0 CVS tree from 9-18-2K. It supports:
> > 1.) fully configurable SSL transport.
> > 2.) UDDI compliant Encrypted Password, signed Distinguished Name
> > Authentication
> > Header.
> > 3.) Diffie-Hellman based triple DESade symmetric encryption environment.
> > (Symmetric encryption is around 1000 times more efficient then a PKI based
> > one).
> >
> > 4. Scripts are provided for both Windows and Linux to build the
Encryption
> > Keys
> > and the Server ACL.
> > 5. ALL features are configurable by information within Soap.configuration
> > files.
>
Re: Secure Soap V2A with extended SSL, authentication and (limited) encryptionsupport
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Hi George,
I don't think we're quite communicating yet .. :-)
Please don't commit any of this to the CVS tree even when you do get
it working. When a committer puts a -1 then that's gotta be removed
before going ahead (or that's my understanding - Sam please correct
me if I'm wrong).
Other committers: if you're also against putting in George's server
side SSL mods please -1 it. IMO it will have a serious negative
impact on Apache SOAP.
I am 200% in favor of client-side SSL support as that's all that's
really needed right now (IMO anyway).
Sanjiva.
----- Original Message -----
From: "George I Matkovits" <ma...@uswest.net>
To: <so...@xml.apache.org>; <ge...@lawson.com>;
<le...@lawson.com>
Sent: Thursday, December 07, 2000 10:45 PM
Subject: Re: Secure Soap V2A with extended SSL, authentication and (limited)
encryptionsupport
> I can not do anything else but hold since the latest CVS tree from 12/6 does
> not seem to work correctly for me. Thank you for your comments, I fully
agree
> with the 'review' process and I will attempt to defend the proposed solution
> here later. Unfortunately, here and everywhere, any and all of the current
> solutions are based on a PKI infrastructure which mandates the use of the
very
> inefficient Public/Private Key technology which is around 1000 times less
> efficient then traditional symmetric keys like tripleDES (DEsade) What would
> this mean for performance? If the overhead of symmetric key encryption on a
> UDDI Server is 10% then you would need additional 100 CPU's (YES additional
> ONE HUNDRED CPUs! :-) to get equivalent performance. This kind of
performance
> is NOT acceptable in a commercial environment. While the cryptographic
> characteristics of the PKI environment are well understood its performance
> implications are NOT, due to the so called Security Community's heavy
> commercial involvement. I am happy that we started the discussion about
PKI's
> commercial promise as far as its 'performance' issues go. Any sane person
(one
> who can count on his/her own fingers :-) will understand that the
> Publiv/Private keys can only be used for a session key definition which
> unfortunately does not work for 'routed' XML documents (someone from IBM
> pointed this out when I first posted the current SSL mods to Soap) between
> UDDI Processing Stations.
> I hope someone will have the best of both worlds ASAP because we need it
NOW.
> SSL does not stop someone from connecting to an UDDI server and deploying a
> 'malicious Trojan' Java program. Only secure one-per-user (encrypted?)
> passwords and an automated methodology for generating the Server's ACL could
> provide the foundation for that.
> Thank you again for your comments. I will post another update as soon as the
> code in the CVS tree works again, currently sequential applications die
> eventually with an 'Connection aborted by peer: JVM_recv in socket input
> stream.' IMHO the problem is with both Servlets new context management code.
> Someone from IBM made the last commit. Could you please use your influence
> within IBM to either undo it or fix the problem (The next, more
comprehensive
> version of SecureSoap, works only against the 9-18 CVS tree :-).
> Regards - George
>
> Darrel Drake wrote:
>
> > George,
> >
> > I was able to more thoroughly review the design points of SecureSoap 2A
> > over the weekend (my Monday), especially as it related to digital
signature
> > and encryption -- as I was not so familiar with this aspect. So I'd like
to
> > elaborate on the concerns that I voiced last week.
> >
> > Client side SSL support for Apache SOAP is a definite need. We all hope
> > that people will use SOAP for real B2B applications, and this development
> > is a step toward SOAP's maturity in that sense. In addition to the
> > transport level confidentiality and integrity that are provided by SSL,
> > SOAP-level security is necessary. However, we may want to consider a
> > different approach than you are currently proposing (at that level).
> >
> > When it comes to XML security, I believe we should take advantage of the
> > current W3C/IETF discussion on XML Signature and XML Encryption as much as
> > possible. Please see the SOAP signature implementation in IBM's Web
> > Services Toolkit (http://www.alphaworks.ibm.com/tech/webservicestoolkit)
> > for our current progress on this issue. Also see
> > http://www.trl.ibm.co.jp/projects/xml/soap/ for related discussions. Since
> > there is no way to mathematically prove the security of a protocol, the
> > only way to achieve a reasonable level of security is thorough review by
> > security experts. Thus, using existing standards will greatly reduce the
> > risk of introducing additional security vulnerabilities.
> >
> > My view, simply put, is that SOAP should leverage existing technologies,
> > not create new ones. Especially in security, since many people believe
that
> > designing a security protocol that is in fact secure is very difficult.
> > Your efforts to improve SOAP security are greatly appreciated by the SOAP
> > user and developer communities. But considering the concerns put forward
> > above, could you hold committing the code beyond beyond the client side
SSL
> > support?
> >
> > Darrell Drake*
> > IBM Japan, TRL
> > +81-46-215-4175
> > EB92401@jp.ibm.com
> > * - Notes ID has a misspelling of my name
> >
> > From: "George I Matkovits" <ma...@uswest.net> on 2000-11-29 20:56
> >
> > Please respond to soap-dev@xml.apache.org
> >
> > To: soap-dev@xml.apache.org, matkovitsg@uswest.net,
> > sanjiva@watson.ibm.com, cnelson@synchrony.net
> > cc:
> > Subject: Secure Soap V2A with extended SSL, authentication and (limited)
> > encryption support.
> >
> > Please find attached the latest version of the SecureSoap work. This
> > version is
> > based on the ApacheSoap2_0 CVS tree from 9-18-2K. It supports:
> > 1.) fully configurable SSL transport.
> > 2.) UDDI compliant Encrypted Password, signed Distinguished Name
> > Authentication
> > Header.
> > 3.) Diffie-Hellman based triple DESade symmetric encryption environment.
> > (Symmetric encryption is around 1000 times more efficient then a PKI based
> > one).
> >
> > 4. Scripts are provided for both Windows and Linux to build the
Encryption
> > Keys
> > and the Server ACL.
> > 5. ALL features are configurable by information within Soap.configuration
> > files.
>