- From: Story Henry <henry.story@bblfish.net>
- Date: Mon, 31 Mar 2008 17:53:12 +0200
- To: foaf-dev Friend of a <foaf-dev@lists.foaf-project.org>, Semantic Web <semantic-web@w3.org>
- Message-Id: <9CF7D079-5B0E-4D41-95C7-4B5C68E0DA4C@bblfish.net>
Another friendly anonymous reader sent me some detailed responses below. I'll forward them on this thread. On 31 Mar 2008, at 16:22, XXX wrote: > Dear Henry, > > You really, really, really, really need a security person! Yes. I know that :-) > For someone who's trying to create a lightweight, simple protocol, > you seem to be diving into some deep waters here. [snip] > Here's a few things: > > Computational expense: > If you are really set on using PGP, you need to be using digital > signatures, not encryption/decryption. For anything over a few > bytes in size, it makes a big difference. ok. Thanks. > Nonces: > The nonce must be a cryptographically secure pseudo random number or > better. You're "ILoveYouToo" example is amusing, but gives entirely > the wrong impression of what a nonce (number used once) really is - > this is dangerous, particularly when no-one in those discussions > understands the security anyway. Ok. I'll fix that on the next update > The client can't provide the nonce, or you are getting no liveness > protection. It's a challenge-response protocol - if the client does > everything there is no protection. Yes, clearly. I was just suggesting that because I was hoping there could be a way to skip step 2 in http://blogs.sun.com/bblfish/entry/rdfauth_sketch_of_a_buzzword > Alice: "I'm Alice with this public key" > Bob: "Encrypt this for me with your private key please > "1234901245y629345781902348y612934690123423042". > Alice:encrypted{"1234901245y629345781902348y612934690123423042"} > Bob: "Hi Alice with that public key!" > > versus: > > Mallory: "I'm Alice with this public key, and I will be encrypting > replay_"1234901245y629345781902348y612934690123423042" for you. > Bob: "Shoot" > Mallory: > replay_encrypted{"1234901245y629345781902348y612934690123423042"} > Bob: "Hi Alice with that public key!". > > Yes, you could get Bob to track all previously used nonces, ever, > for everyone, for all time. I think you can see the fatal flaw in > that proposal. Timestamps are a possibility - you must define an > acceptable window of time (clients and servers will generally not be > synched). Yes, I can see how things get complicated here. A lot of the art in protocol design is balancing complexity. This is where I was hoping for feedback from HTTP people on how this has been done before. > However, in your current proposal, the server still has to track > nonces that are currently issued, and hook that up with the > following requests it gets. You will need to expire these after > some time of not being used, or you will fill up your connection > tables. Lots of connection attempts that don't follow up will cause > another denial of service. You also need to expire these when they > are used (to prevent future replay). Obviously, a connection using > a nonce not in the table must be rejected, even if the message > otherwise validates. ok. :-) > Authentication and session protocols > > >"The second time the UA can immediately jump to step 4." > > > >Which nonce does it use? Or, how could this reuse be distinguished > from a replay attack? > > No, you can't jump to step 4, or you don't have a nonce. You cannot > distinguish reuse from replay attacks in the protocol as its > designed. If you want to establish a session that's less > computationally expensive than the original authentication - a > frequent reason for doing this - then you need a secure session > protocol as well. Yes, that sounds like a good idea. I wonder how this idea plays with SSL ? > > Ed Davies wrote, in a reply to http://blogs.sun.com/bblfish/entry/rdfauth_sketch_of_a_buzzword > >If the Capulets can watch the HTTP traffic to see the request (4) > in order to replay it then, presumably, they can also see the reply > (9) in which >case that reply would also need to be encrypted, with > Romeo's public key I would imagine. In which case, what's the harm > of a replay attack? > > Very good point. It doesn't provide additional confidentiality > regarding that attacker, but they could post a non-replay protected > connection string for anyone to get the data at will, forever > afterwards, making the protection worthless after the intial hack. > Unless it's replay protected. > Ed Davies wrote: > > I'm not even sure of that - I don't know enough about cryptography > but I imagine any practical encryption would put a salt in. > > Salt isn't really used in encryption situations - it's used to > protect against dictionary lookup attacks against hashed values > where there is no secret key, just a secret, fixed value. > > > Would this all be better going over HTTPS anyway? > > Normal HTTPS would only provide you with confidentiality of > information over the session, and authentication of the server to > the client, not the client to the server. You can use it for mutual > authentication if you like, using client certificates. This would > probably do everything that you're after - mutual authentication, > confidentiality, secure sessions, standard protocols. Not many > people use mutual SSL though - don't know how well it works in > practice. Might be worth exploring, rather than designing your own > public key protocol. Thanks for the pointer. From wikipedia [[ The system can also be used for client authentication, in order to restrict access to a Web server to only authorized users. For this, typically the site administrator creates certificates for each user which are loaded into their browser. These normally contain the name and e-mail address of the authorized user, and are automatically checked by the server on each reconnect to verify the user's identity, potentially without ever entering a password. ]] http://en.wikipedia.org/wiki/Https Ok, so what we are looking for perhaps is the use of client certificates that work well with Linked Data. > > > "I had always thought of using HTTPS myself, but now I think of it, > why indeed not encrypt the response with Romeo's public key? Then, > as you point out, only he could read it anyway. That could simplify > the protocol even further..." > > Well, that would certainly protect the response, at a frighteningly > high computational cost. You do know that SSL doesn't use public > key encryption to encrypt the actual messages? It uses symmetric > key encryption with only the key negotiation protected by the public > key. This is entirely down to the cost of public key encryption. Yes, I was wondering *how* expensive this is though. But this remark does come up again and again :-) > > Encryption / Decryption services > > If you're going to provide a convenient service that does the > encryption for you, how does it know who is authorised to use the > service? Now that service needs to authenticate you too. This > authentication mechanism clearly can't be RDFAuth, or you've just > gone into an infinite loop! So you need two authentication protocols. yes that was an initial thought. I suppose the same remark will be made for a token service. The token service also requires authentication. That is why I then later thought that it may be easier if the agents had their own keys that could be linked from the user's public foaf file as being those of trusted agents. > I'm finding the "simpler" you want to make this (i.e. you can use > PGP and hack it together with a perl script), the more complicated > and expensive the protocol seems to be getting! I'm afraid I don't > quite know where you could find someone who understands protocol > design - maybe make a request on a security mailing list? Yes, some of my attempts at simplifications were making things more complicated. Such as trying to avoid step 2. Others such as creating a PGP server clearly make everything even more complex. My feeling is that this will be true of a token server too. At some level though this is simpler than OpenId, which is odd. My feeling is that what is needed is to see how this could be made to work better with SSL. The idea in all this is to make use of Linked DAta in order to get a distributed web of trust security mechanism which can allow hyperdata browsers such as Beatnik to quickly get information distributed around the web, even when it is protected. OpenId is too complicated. What we are proposing here is probably wrong, but is getting a lot simpler. So yes, we do need HTTP and security experts to help locate the optimal solution here. Thanks for the feedback, Henry > Regards, > > XXX >
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 31 March 2008 15:54:08 UTC