Cart
[Home] [By Thread] [By Date] [Recent Entries]
<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>
|
