protocol problems and concerns

[dkg]

Thanks for proposing this mechanism.  It's great to see asymmetric crypto proposals that might address some of the underlying problems with the current authentication woes that plague the 'net.

However, I have a couple concerns about protocol specifications with gpgAuth, as i understand it from reading http://www.gpgAuth.com/ -- i haven't done a full review yet, but i wanted to raise these issues, and this forum seems to be the only place to do so.

ignoring usage flags on keys

The OpenPGP RFC section 5.2.3.21 declares specific usage flags for keys: http://tools.ietf.org/html/rfc4880#section-5.2.3.21

These usage flags declare the appropriate use of keys and subkeys, distinguishing between keys that should be used for authentication, keys that should be used for signing,  keys that should be used for encryption, etc.  I could find no reference to the specific key flag requirements in the gpgAuth docs i read.  This is probably just an oversight, but it would be worth rectifying.

attacks against encrypted data

Consider the case of a user X attempting to authenticate using gpgAuth to server Y.  Let's assume that Y is evil (e.g. it has been compromised, the administrator has had a change of heart, whatever), but X doesn't know this.  Suppose that the attacker in control of Y has intercepted a separate message intended for X, but it was encrypted.  What is to stop Y from offering that encrypted message as its "random data" to X.  X is then obliged by gpgAuth to decrypt the data, and return it to Y.  Y now has access to the secret message originally intended for X.

proxy/replay attacks

in the same scenario as above, with user X and server Y, where Y has turned evil:  Let's assume that Y also knows that X might have an account on server Z, which also uses gpgAuth.  What is to stop Y from masquerading as X to Z in a proxy/replay attack?  For example, X initiates a connection to Y.  Y quickly initiates a connection Z, claiming to be X, and requests the gpgAuth data.  Y then takes the encrypted challenge from Z, and hands it back to X.  X decrypts it, returning the result to Y.  Y decrypts it, re-encrypts it to Z, and passes it back to Z.  Now Y has an authenticated session (as X!) to Z.

Can you help me understand why the above concerns shouldn't worry me?  Or propose changes to the protocol that might mitigate the concerns?

(btw, it's difficult to link to specific details of a specification if the details are only reachable through the use of javascript -- have you considered providing the data as static HTML so that we can communicate more precisely?)

Regards,

  --dkg

   my OpenPGP fingerprint = 0EE5 BE97 9282 D80B 9F75  40F1 CCD2 ED94 D217 39E9

[chris_acheson]

attacks against encrypted data

This could be solved by having the user return a hash of the decrypted data, rather than the data itself.

proxy/replay attacks

I haven't looked at the code yet, so this might already be done, but signing the data in addition to encrypting it should prevent this, right?

[dkg]

Yes, i think having the user return a hash of the decrypted data would be a reasonable countermeasure to the "attacks against encrypted data"

Re: proxy/replay attacks

I haven't looked at the code yet, so this might already be done, but signing the data in addition to encrypting it should prevent this, right?

I haven't looked at the code either.  i'm working from what i understand of the protocol, as published (sort of, in a weird javascript way) on this site.

It sounds to me like you are suggesting that each party would sign its data request before encrypting it, and then hand over CHALLENGE=encrypt(to:peer,sign(from:self,data)) to the receiving party.  the receiving party would then verify(from:peer,decrypt(CHALLENGE)), and if it checks out, would return RESPONSE=hash(data).

Is this right?  That certainly seems better to me than the original proposal, but i haven't had a chance to think through all the other angles.

I suspect that if this standard wants wider adoption, a precise, exhaustive, statically-readable, clearly-versioned normative specification needs to be published for peer review.

It's still unclear to me what this particular specification offers that would not be covered by TLS with OpenPGP keys, though.  How do they differ functionally?

[chris_acheson]

It sounds to me like you are suggesting that each party would sign its data request before encrypting it, and then hand over CHALLENGE=encrypt(to:peer,sign(from:self,data)) to the receiving party.  the receiving party would then verify(from:peer,decrypt(CHALLENGE)), and if it checks out, would return RESPONSE=hash(data).

Pretty much.  When (as per your example) Y passes Z's gpgAuth data to X, X would decrypt it, check the signature, find that it wasn't signed by Y, and the jig is up.

It's still unclear to me what this particular specification offers that would not be covered by TLS with OpenPGP keys, though.  How do they differ functionally?

I wasn't aware of that, actually.  It looks like it's integrated into mod_gnutls for Apache, but I can't find anything about browser support.  Once it's actually implemented and adopted, it sounds like that's the holy grail.

[dkg]

Unfortunately, the gpgauth author does not seem to be responding to this thread.  Perhaps that's because the project is abandoned?

I found a discussion on enigform's forum that suggests that Kyle Huff (the original gpgAuth author) is proposing abandoning gpgAuth entirely in favor of enigform and apache's associated mod_auth_openpgp.  As such, i plan on moving my cryptographic review to that suite of tools, and suggest that people avoid using gpgAuth entirely unless more information is forthcoming.

[kylehuff]

The project has not been abandoned - just severely neglected due to other projects and my work schedule.

In my talks with the author of openpgp my suggestion that gpgAuth is obsolete was predicated on like functionality (website authentication) in maopenpgp. At the time, this was not being done. I have not checked recently to see if maopenpgp provides a seamless PGP/GPG method for authenticating users for a secured web session. (The openpgp approach is very different than gpgAuth, I believe the focus was more for using PGP/GPG to encrypt the underlying transport of HTTP requests/posts.)

Anyway - having said that - there is not much for me to do in regards to gpgAuth other than answer questions (which, admittedly, I am failing miserably!), gpgAuth is less of a product than a mechanism. It is a series of events. The sources provided here are merely to accomplish the user authentication using PGP/GPG - and are in python, because that is what I know. In reality, the same process could be done using PHP, Perl, ASP, etc.. It is a drop-in-place method for performing authentication that aims to be architecture agnostic.

Now, the gpgAuth module in FireGPG is a product, a product that uses methods discussed here to interact with the server - which is still maintained.. Although, I might be the only person using it....

I will answer your other questions regarding the underlying mechanisms later, as it will take some time to explain. I will answer even though it may be irrelevant to you at this point, as it has been months since you asked. (Sorry, again, I have been very very busy with work, other projects and life events.. [ new kid, serious motorcycle accident, and a few others ]....)

Kyle Huff

[dkg]

Hi Kyle -- I'm glad to hear from you, though i'm sorry to hear about your accident.  That's terrible, and i hope you're recovering well!

i'm certainly still interested in the details for gpgauth, and they're pretty relevant to me as i may soon become the debian maintainer for firegpg, which upstream includes as a gpgauth client implementation.  I want to make sure that the package doesn't leave its users vulnerable to malicious servers.

[kylehuff]

ignoring usage flags on keys

The OpenPGP RFC section 5.2.3.21 declares specific usage flags for keys: http://tools.ietf.org/html/rfc4880#section-5.2.3.21

These usage flags declare the appropriate use of keys and subkeys, distinguishing between keys that should be used for authentication, keys that should be used for signing,  keys that should be used for encryption, etc.  I could find no reference to the specific key flag requirements in the gpgAuth docs i read.  This is probably just an oversight, but it would be worth rectifying.

I will have to look into this as I have time.

attacks against encrypted data

Consider the case of a user X attempting to authenticate using gpgAuth to server Y.  Let's assume that Y is evil (e.g. it has been compromised, the administrator has had a change of heart, whatever), but X doesn't know this.  Suppose that the attacker in control of Y has intercepted a separate message intended for X, but it was encrypted.  What is to stop Y from offering that encrypted message as its "random data" to X.  X is then obliged by gpgAuth to decrypt the data, and return it to Y.  Y now has access to the secret message originally intended for X.

The gpgAuth implementation that is included in FireGPG will only return a decrypted token if the data contains a certain predefined string. So as long as you don't make it a habit to encrypt your secure data with with this very specific string (a preamble and postamble which includes the major version number of the gpgAuth implementation) - this should never be an issue.

proxy/replay attacks

in the same scenario as above, with user X and server Y, where Y has turned evil:  Let's assume that Y also knows that X might have an account on server Z, which also uses gpgAuth.  What is to stop Y from masquerading as X to Z in a proxy/replay attack?  For example, X initiates a connection to Y.  Y quickly initiates a connection Z, claiming to be X, and requests the gpgAuth data.  Y then takes the encrypted challenge from Z, and hands it back to X.  X decrypts it, returning the result to Y.  Y decrypts it, re-encrypts it to Z, and passes it back to Z.  Now Y has an authenticated session (as X!) to Z.

Currently, this a trust issue. If you do not trust the server, why are you using it? Having said that, this is not a perfect world, and things change for the worse sometimes faster than you can update your trust model. So the server needs to encrypt the user token AND SIGN IT.. Currently, that is not being validated within the gpgAuth module of FireGPG. So with the usage of encrypt+sign in your X, Y, Z scenario, it should play out as:

X makes a request to Y, who quickly makes a request to Z, Z encrypts [and signs] a token to the public key of X, Y can not decrypt it, so Y hands the token to X for decryption, the decrypting client verifies the signature is valid and matches the fingerprint to the fingerprint in the local keyring associated with that userid "Y.com", it will see that the fingerprint will not match "Y.com" and thus fail.

(btw, it's difficult to link to specific details of a specification if the details are only reachable through the use of javascript -- have you considered providing the data as static HTML so that we can communicate more precisely?)

I will work on this - I agree, it is difficult to read in the current presentation. I will see what I can do. However, I just want to point out - the gpgAuth module is not really a part of gpgAuth - gpgAuth is simply a way for a webserver to validate users using gpg.. the gpgAuth module in FireGPG is simply a tool to provide the user with an easy way to transfer the tokens back and forth - and do some security checks. Having said that - the gpgAuth module of FireGPG does need to be documented here, both the source and the process. Again, I will work on this..

So, in summary -
ignoring usage flags on keys - I will look at this as time permits.

attacks against encrypted data - Validation of any encrypted token will fail if it does not contain the gpgAuth {pre,post}-amble.

proxy/replay attacks - Currently the mechanism relies entirely on trust - so this is a possible scenario. This issue can be resolved by keysig verification and keysig fingerprint matching to the local keyring for the specific server-key. I have already implemented this feature into the gpgAuth module for FireGPG - but I have not yet submitted it for inclusion into FireGPG - as testing is a very slow process. Attached is a screenshot of what happens when a token is not signed by the key associated with the domain you are visiting.

Please let me know if you need further explanation or example. Also feel free to contact me via a messenger service; my details are in my profile.

Kyle

[dkg]

thanks for the thoughtful feedback, kyle.

The gpgAuth implementation that is included in FireGPG will only return a decrypted token if the data contains a certain predefined string

If the preamble and postamble is intended to avoid the attacks described against encrypted data, it should probably be an explicit requirement in the protocol, not just an implementation choice made by the first client.  Requiring that the nonce be signed by the server as well might be an additional protection against this attack.

So the server needs to encrypt the user token AND SIGN IT.

I think you meant this the other way around, right?  It seems important to me that the signature over the nonce should itself be wrapped by the encryption, rather than signing the encrypted nonce.   Otherwise, a machine performing a proxying/relaying attack (Y) could strip the signature made by the victim server (Z) and re-sign the encrypted nonce before passing it off the user (X).  You probably already understand this, but i wanted to make it explicit.

Currently, this a trust issue. If you do not trust the server, why are you using it?

I think this question confuses multiple ideas of trust, and is basically a non-starter for any discussion of secure network communication.  A user might reasonably connect and authenticate to a known server, and trust it to provide certain information, but not trust it to behave responsibly in any other context.

For example, consider a researcher A hired to do a security audit of company B's infrastructure.  In order to know what systems in particular are under contract for auditing, A needs to authenticate herself to B's web server to receive her instructions. But she hasn't begun the audit yet, so she cannot know how this web server is set up, or what it is capable of doing or doing wrong.  Researcher A should be able to prove her identity to the server without allowing that server to masquerade as her to any other entity on the network, and without risking disclosure of the contents of any other unrelated secure communications.

I agree, it is difficult to read in the current presentation. I will see what I can do. However, I just want to point out - the gpgAuth module is not really a part of gpgAuth - gpgAuth is simply a way for a webserver to validate users using gpg.. the gpgAuth module in FireGPG is simply a tool to provide the user with an easy way to transfer the tokens back and forth - and do some security checks. Having said that - the gpgAuth module of FireGPG does need to be documented here, both the source and the process. Again, I will work on this..

I probably didn't make this clear: while i'm interested in documentation of the FireGPG module that implements gpgauth, i'm *more* interested in documentation of the gpgauth protocol itself.  In order to get a clear cryptographic understanding of the protocol, it would be really helpful to have a document describing the protocol that has something approximating the following properties:

 * a clear version number and date of last modification
 * is all in one static HTML or text file -- no dynamically-loaded content
 * has explicit section and subsection numbers, so that pieces of the protocol can be clearly referenced.

If the intent is to make this protocol something useful to the general public (as appears to be the goal with its inclusion with FireGPG), then the protocol spec should probably also be proposed to other interested users and implementors.  Once you have a draft of a referenceable document, I recommend joining the IETF OpenPGP working group mailing list: http://www.imc.org/ietf-openpgp/ and pointing other members of the WG to the draft so there can be a wider community review.

Thanks for your work on this, Kyle.

[kylehuff]

The gpgAuth implementation that is included in FireGPG will only return a decrypted token if the data contains a certain predefined string

If the preamble and postamble is intended to avoid the attacks described against encrypted data, it should probably be an explicit requirement in the protocol, not just an implementation choice made by the first client.  Requiring that the nonce be signed by the server as well might be an additional protection against this attack.

I agree; it should be a requirement of the protocol specification for public use. And you are right, if the token was signed by the server this would not be much of an issue - however the check is in place for cases where you don't care about the signature but you still don't want to be tricked into decrypting something that has been encrypted to your public key that may be sensitive. For example - I have used this mechanism to authenticate into protected areas of an intranet - a controlled environment where I am reasonably assured that the server I am communicating with is trustworthy - and I don't want to worry about having up-to-date versions of those controlled servers public key, or managing the UIDs of those server keys  (These are servers isolated from the internet and controlled by myself or a limited number of trustworthy individuals.).

So the server needs to encrypt the user token AND SIGN IT.

I think you meant this the other way around, right?  It seems important to me that the signature over the nonce should itself be wrapped by the encryption, rather than signing the encrypted nonce.   Otherwise, a machine performing a proxying/relaying attack (Y) could strip the signature made by the victim server (Z) and re-sign the encrypted nonce before passing it off the user (X).  You probably already understand this, but i wanted to make it explicit.

Yes, I should have been more clear - I mean the encrypted data should contain a valid signature of the server key associated with the domain. A wrapped signature would be mostly useless.

Currently, this a trust issue. If you do not trust the server, why are you using it?

I think this question confuses multiple ideas of trust, and is basically a non-starter for any discussion of secure network communication.  A user might reasonably connect and authenticate to a known server, and trust it to provide certain information, but not trust it to behave responsibly in any other context.

For example, consider a researcher A hired to do a security audit of company B's infrastructure.  In order to know what systems in particular are under contract for auditing, A needs to authenticate herself to B's web server to receive her instructions. But she hasn't begun the audit yet, so she cannot know how this web server is set up, or what it is capable of doing or doing wrong.  Researcher A should be able to prove her identity to the server without allowing that server to masquerade as her to any other entity on the network, and without risking disclosure of the contents of any other unrelated secure communications.

I was being facetious regarding trusting every server you log into  =c )
If we could safely assume any decent level of trust for un-established or even established servers out on the internet - I would not be spending any time on this..

I agree, it is difficult to read in the current presentation. I will see what I can do. However, I just want to point out - the gpgAuth module is not really a part of gpgAuth - gpgAuth is simply a way for a webserver to validate users using gpg.. the gpgAuth module in FireGPG is simply a tool to provide the user with an easy way to transfer the tokens back and forth - and do some security checks. Having said that - the gpgAuth module of FireGPG does need to be documented here, both the source and the process. Again, I will work on this..

I probably didn't make this clear: while i'm interested in documentation of the FireGPG module that implements gpgauth, i'm *more* interested in documentation of the gpgauth protocol itself.  In order to get a clear cryptographic understanding of the protocol, it would be really helpful to have a document describing the protocol that has something approximating the following properties:

 * a clear version number and date of last modification
 * is all in one static HTML or text file -- no dynamically-loaded content
 * has explicit section and subsection numbers, so that pieces of the protocol can be clearly referenced.

If the intent is to make this protocol something useful to the general public (as appears to be the goal with its inclusion with FireGPG), then the protocol spec should probably also be proposed to other interested users and implementors.  Once you have a draft of a referenceable document, I recommend joining the IETF OpenPGP working group mailing list: http://www.imc.org/ietf-openpgp/ and pointing other members of the WG to the draft so there can be a wider community review.

I agree with this; I think I should make it clear that designing a protocol was not my original intent. When thinking about the problems plagued with the traditional authentication used on the public internet (and most everywhere else too), I was totally disgusted. I started thinking about how GPG/PGP could resolve a lot of the issues - but it was really complicated passing data back and forth, encrypting, signing, decrypting, verifying, etc.. So I started playing with a firefox extension and some really simple (python-based) server side scripting.. and it worked.. with the right tools it was no longer cumbersome.

The intent was originally just to prove it could be accomplished with minimal effort - and it could be done as drop in authentication system on the server-side - by 'drop-in' I mean limited or no changes to the server and basically webserver technology agnostic. It seemed to me like the holy grail for authenticating users to websites. Easier for users - easier for providers, and was a starting point to develop a mechanism to verify the identity of the server without paying for expensive signed certificates.

Anyway, I guess I imagined people jumping on board to help make it usable - to develop it into something standardized and official - which is why I asked the FireGPG guys to include the client into their extension, an extension which is directly GPG related, and an extension I and many other people use daily. Having it included in the extension I was in hopes that it would remove the excuse of "it is too hard for the users" to implement GPG based web authentication. But alas, it sounds like I need to write a protocol reference.. =c )

I have no idea how to do so.. but I have reviewed enough of them and that is the same thing, right? =c )  (yes, I am again being facetious..)

I will see what can work up regarding a specification.

Thanks for all of your input in this.

Kyle

[dkg]

Having it included in the extension I was in hopes that it would remove the excuse of "it is too hard for the users" to implement GPG based web authentication. But alas, it sounds like I need to write a protocol reference.. =c )

I think your implementation does address the concern of "it is too hard for the users", which is exciting because it shows that something like this is possible. 

But by not having a clear, publicly-reviewed specification for what's going on at the cryptographic layer, you've left open questions about exactly how secure this "easy for users" system is.  Since i assume your goals are similar to mine (i suspect we both want to hit the intersection of cryptographically-secure and user-friendly), that's the place where i'm pushing you.  Had you written a cryptographically-rigorous spec, but left major gaps in the user-friendliness, i'd probably be pushing you about the UI.  No good deed goes unpunished!

I look forward to reading a specification.  I'd be happy to read drafts as well, if you like.

[kylehuff]

I think your implementation does address the concern of "it is too hard for the users", which is exciting because it shows that something like this is possible. 

But by not having a clear, publicly-reviewed specification for what's going on at the cryptographic layer, you've left open questions about exactly how secure this "easy for users" system is.  Since i assume your goals are similar to mine (i suspect we both want to hit the intersection of cryptographically-secure and user-friendly), that's the place where i'm pushing you.  Had you written a cryptographically-rigorous spec, but left major gaps in the user-friendliness, i'd probably be pushing you about the UI.  No good deed goes unpunished!

I look forward to reading a specification.  I'd be happy to read drafts as well, if you like.

Ha! Honestly - the extension part was easy for me - that is the type of thing I enjoy working on, especially when it is regarding something that I think is useful. As for the protocol specification, ugh.. I like that type of stuff about as much as I like filing my taxes.. But, it does need to be done. And now that I am in communication with someone who sounds familiar with the process and is offering to review the material (read: YOU), I am running out of excuses...

I will be sure to get something to you as soon as I can.