[
Lists Home |
Date Index |
Thread Index
]
<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@metalab.unc.edu
> 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>
|
