|
[XML-DEV Mailing List Archive Home]
[By Thread]
[By Date]
[Recent Entries]
[Reply To This Message]
Re: Re: Cookies at XML Europe 2004 -- Call forParticipation
<Quote1>
Your real world example is based on SAML, a system which is not
actually used in browsers today, and seems unlikely to be in at least
the near future.
</Quote1>
Not meaning to move the discussion off track, but wanted to mention that
SAML has a Web browser profile - see line 377 of [1].
<Quote2>
Even if you convince me that HTTP over SSL is not secure enough,
(which would require showing it's susceptible to being decrypted, not
merely a denial of service) I am sadly still unconvinced that we will
get better security than that, even if it's available.
</Quote2>
I have very high hopes for the potential of OASIS WS-Security[2], whose
approval as an OASIS standard is imminent.
Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton
Strategy and Technology Consultants to the World
[1]
http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bindings-1.1.pdf
[2] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
Elliotte Rusty Harold wrote:
>
> At 2:30 PM -0500 1/7/04, Rich Salz wrote:
>
> >Here's a real-world example. A big bank down in New York has a deal
> >with a small online bookseller that BB's employees get a discount.
> >The BB hands the seller the public key of its HR SAML server. When
> >an employee wants to buy a book, they present a SAML assertion to
> >the seller. The seller checks the signature, sees it came from BB
> >HR, and gives the employee the discount. This is the best way to do
> >things. BB is not going to give its employee list to the seller --
> >their are privacy issues, out-of-sync issues, etc. Requiring
> >real-time seller->BB "is XXX an employee" queries adds too much
> >overhead and fragility to the system.
>
> Your real world example is based on SAML, a system which is not
> actually used in browsers today, and seems unlikely to be in at least
> the near future. You're moving the goal posts. I'm talking about
> browsers and web servers, and you're off into web services, a very
> different scenario. Can you provide a real world example of the
> problem using standard browsers?
>
> >A very small saml assertion is about 500 bytes. A signature on that
> >message is between 1000 and 1500 bytes (depending on if the
> >certificate is included or not), so we're up to around 2K. If the
> >identity is encrypted -- perhaps the bank wants to ensure that only
> >the bookseller gets to see this employment assertion -- than add
> >another 100 or so bytes and increase the 2K by 33% (base64), and
> >we're approaching 3K.
> >Following REST principles, that information has to be sent every
> >time the employee contacts the seller's website. Is it scalable to
> >require 3K overhead on every single transaction?
>
> Yes. 3K extra per page doesn't set off my alarm bells for desktop
> systems and servers, and I'm not willing to compromise the design of
> desktop systems and servers to fit the mostly theoretical needs of
> smaller devices.
>
> >The examples you've been using are all limited because they show you
> >as a specific entity interacting with the web site. Many
> >transactions -- most, in the web services world -- are entities
> >*within an organization* acting with another entity *within an
> >organization.* For that kind of interaction, TTP is a must for the
> >reasons I listed above: scalability, privacy, and data-liveness.
>
> To the extent that your problems only involve web services, I claim
> that web services are broken. It is not OK to break HTTP and the HTTP
> architecture to force it to do things it was never meant to do. This
> has been a huge problem with web services since XML-RPC was invented
> as a way of sneaking through firewalls. There are things people want
> to do with web services for which HTTP is not an appropriate
> protocol. These services should use a different protocol, rather than
> trying to cut HTTP apart and reglue it back together again with
> pieces from other protocols to produce some ugly Franken-protocol
> that will never work as well as an appropriately designed protocol.
> Not all protocols have to be stateless. But HTTP is.
>
> >The paragraphs above tried to justify the size and crypto overhead
> >-- why the data is what it is. Now let's talk about processing
> >cost. On my 1Ghz/384Meg workstation, verifying a 2K file (small
> >data, small signature as described above) takes about 2 msec. I
> >used xmlsec (www.xmlsec.org), which is built on openssl and Gnome
> >XML libraries, so I'm using standard and very fast software. I
> >didn't test, but encryption is probably similar, since it has
> >another RSA operation, but instead of XML canonicalization feeding
> >into SHA1, it has base64 decode feeding into 3DES (triple-DES) or
> >AES.
>
> 2ms. I would have guessed more. That's why measuring is important.
> Again, this is not large enough that making a compromise in the name
> of increased speed at the cost of architecture seems wise to me.
>
> >Perhaps more importantly, by having the client present the security
> >context, the server is now very suceptible to denial of service
> >attacks. It's trivial for an adversary to make a realistic message
> >-- no crypto involved, just send random base64 bytes -- and send it
> >over and over again forcing the server to do lots of needless work.
> >This is not a "throw more horsepower at it" issue, it is an
> >architectural issue. If I have faster hardware, so does my
> >adversary. As long as the processing is asymmetric -- as long as
> >the server must validate the client on most transactions -- the
> >weakness is intrinsic to the design.
>
> OK. I can see that. Is this not a problem in your architecture? If
> I'm understanding this attack correctly, using state would only
> remove the need to verify after the initial, verified transaction.
> Can the attacker not send just as many initial, malformed requests?
> How does maintaining state present this attack?
>
> >Given that both good and bad guys benefit from increased
> >efficiencies, do you now see why it's a fundamental principle?
>
> I see you're thinking here more about the DOS than key theft. For key
> theft, the good guys and the bad guys do not benefit equally from
> increased efficiencies. For DOS, they may, though you still have to
> convince me that DOS is not a problem with your architecture relative
> to the HTTP architecture.
>
> In practice, DOS is a problem today with HTTP irregardless of
> encryption. In practice, DOS attacks are dealt with by cutting off
> attacking hosts at the router. This would still be an equally
> effective (or ineffective) response to DOS in the future. I'm not
> sure either encryption approach would have much practical impact on
> DOS attacks.
>
> >It is a compromise and it is necessary, but it is not useful. As
> >the authors themselves put it, "it is better than nothing." As web
> >services exchange real value or real liability (e.g., your doctor's
> >office sending a prescription renewal the pharmacy closest to your
> >conference hotel), we will need much better than that and the
> >compromise will have to tip toward security and away from REST.
>
> Anything like this should be done with SSL.
>
> Even if you convince me that HTTP over SSL is not secure enough,
> (which would require showing it's susceptible to being decrypted, not
> merely a denial of service) I am sadly still unconvinced that we will
> get better security than that, even if it's available. Compare the
> case today where the doctor's office calls the pharmacy on the phone.
> This goes in the clear, unencrypted, over lines that have been
> specifically designed to allow U.S. law enforcement agencies to
> listen in on any conversation by flipping a switch. Furthermore the
> switches that control these taps may well be open to other bad actors
> as well. See http://www.pbs.org/cringely/pulpit/pulpit20030710.html
>
> --
>
> Elliotte Rusty Harold
> elharo@m...
> Effective XML (Addison-Wesley, 2003)
> http://www.cafeconleche.org/books/effectivexml
> http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
|
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format
| RSS 2.0 |
 |
| Atom 0.3 |
 |
| |
Stylus Studio has published XML-DEV in RSS and ATOM formats,
enabling users to easily subcribe to the list from their preferred news reader application.
|
Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website.
they were not included by the author in the initial post. To view the content without the Sponsor Links please
click here.
|
|
Cart
