Re: RDFAuth: an initial sketch

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
>