Re: gpg-agent branch treats PGP passphrase as repository password?

[Daniel Shahaf]

Greg Hudson wrote on Mon, Dec 06, 2010 at 10:31:05 -0500:
> On Mon, 2010-12-06 at 07:30 -0500, Daniel Shahaf wrote:
> > Ideally, Subversion won't know the PGP passphrase.  (If it does, then
> > a malicious libsvn_subr can compromise a private key.)
> 
> I think you're trying to solve a different problem here.  The goal is to
> minimize typing of passwords without storing passwords in a fixed
> medium, not to protect keys against malicious or broken Subversion code.
> 

Agreed, there are two different problems here:

P1.  Minimize typing of passwords.
S1a. Cache the password in gpg-agent.

P2.  Do not store passwords on disk in plaintext.
S2a. Encrypt the passwords with GPGME before storing them to disk.

I was commenting on Stefan's suggestion that Subversion should
explicitly know the passphrase of some PGP key.  (I'm assuming some
people will use for this purpose the same PGP key they use for email
communications.)

> > For comparison, the ssh-agent protocol[1] only allows a client of the
> > agent to authenticate himself (using the agent) to a third party, but
> > does not have a "Retrieve secret key" option [2].  If we are to use PGP,
> > could we find a solution with similar properties?
> 
> ssh-agent has special knowledge of the operations which will be
> performed using the keying material.  PGP probably doesn't have any
> interest in the operations Subversion needs to do with passwords.
> 

I'm not sure I understand this comment.  Originally, I assumed that PGP
might implement a generic   lambda ctxt: decrypt(pgp_sk, ctxt)   interface.

> PKCS#11 is the most commonly used general API for operations where an
> application can use a key but isn't allowed to know what it is.  The
> most useful free software implementation of PKCS#11 is probably NSS.  I
> don't think we want to go there, though.
> 

We only have the "Subversion isn't allowed to know the key" requirement
if that key is used by something other than Subversion.  Therefore, an
alternative is to require keys that are used only by Subversion (so
leaking the passphrases compromises nothing but ~/.subversion/auth/):

* we could store a secret gpg keyring under ~/.subversion/.gnupg/ :-)

* we could use symmetric passwords (as I suggested elsethread)

> 

Thanks for your comments,

Daniel

Re: gpg-agent branch treats PGP passphrase as repository password?

[Greg Hudson]

On Mon, 2010-12-06 at 07:30 -0500, Daniel Shahaf wrote:
> Ideally, Subversion won't know the PGP passphrase.  (If it does, then
> a malicious libsvn_subr can compromise a private key.)

I think you're trying to solve a different problem here.  The goal is to
minimize typing of passwords without storing passwords in a fixed
medium, not to protect keys against malicious or broken Subversion code.

> For comparison, the ssh-agent protocol[1] only allows a client of the
> agent to authenticate himself (using the agent) to a third party, but
> does not have a "Retrieve secret key" option [2].  If we are to use PGP,
> could we find a solution with similar properties?

ssh-agent has special knowledge of the operations which will be
performed using the keying material.  PGP probably doesn't have any
interest in the operations Subversion needs to do with passwords.

PKCS#11 is the most commonly used general API for operations where an
application can use a key but isn't allowed to know what it is.  The
most useful free software implementation of PKCS#11 is probably NSS.  I
don't think we want to go there, though.

Re: gpg-agent branch treats PGP passphrase as repository password?

[Daniel Shahaf]

Stefan Sperling wrote on Sun, Oct 17, 2010 at 16:03:13 +0200:
> The GPGME library will probably help with these steps:
> http://www.gnupg.org/gpgme.html

By the way, the GPGME library supports symmetric (password-keyed, as
with 'gpg -c') encryptions [1], in addition to PGP assymetric
encryptions.

What is it good for?  To remember just one password (the symmetric
password) instead of N password cached by Subversion.  Otherwise it
just adds a layer of redirection...

> I haven't checked, but it's possible that this library will talk to
> the GPG agent on behalf of Subversion.

[1] 
,
documentation of recp=NULL.

Re: gpg-agent branch treats PGP passphrase as repository password?

[Daniel Shahaf]

[ crypto student hat on ]

Stefan Sperling wrote on Sun, Oct 17, 2010 at 16:03:13 +0200:
> Retreiving a password:
> Step 1: svn contacts the gpg-agent to find out the passphrase for the
> private pgp key the agent is managing. If the agent cannot be
>   contacted svn asks the user for the passphrase.
> Step 2: svn uses this passphrase to decrypt the user's PGP private key

Ideally, Subversion won't know the PGP passphrase.  (If it does, then
a malicious libsvn_subr can compromise a private key.)

For comparison, the ssh-agent protocol[1] only allows a client of the
agent to authenticate himself (using the agent) to a third party, but
does not have a "Retrieve secret key" option [2].  If we are to use PGP,
could we find a solution with similar properties?

> Step 3: svn uses this private key to decrypt the password stored
> inside the ~/.subversion/auth area
> Step 4: svn sends the decrypted password to the server
> 
> The GPGME library will probably help with these steps:
> http://www.gnupg.org/gpgme.html

It seems straightforward enough to use this for decryption.  However,
does this library provides access control?  Namely, does it allow the
end user to say "libsvn may perform decryptions, but may not export
secret keys"?

> Thanks,
> Stefan

[1] 
,
Section 2.6 and Section 3.

[2] This is documented in ssh(1) under the -A option.

Re: gpg-agent branch treats PGP passphrase as repository password?

[Stefan Sperling]

On Wed, Dec 01, 2010 at 06:29:06PM -0500, Dan Engel wrote:
> On Wed, 2010-12-01 at 14:08 +0100, Stefan Sperling wrote:
> > However, I still see a potential risk here because the name
> > "gpg-agent"
> > is very misleading. It violates the principle of least surprise.
> > How can we prevent users misunderstanding what "Subversion's gpg-agent
> > feature" does from entering their private pgp key passphrase (which
> > will
> > then be sent to the server)?  Can we control the prompt printed by
> > gpg-agent? ("Enter your Subversion password, NOT your secret PGP
> > passphrase!") 
> 
> 
> Yes, the agent protocol provides for customized prompts, and the patch
> itself refers to the Subversion repository server (or something like
> that) in that prompt.

If we can control the prompt, then let's just make the prompt
clear enough so that people who read it don't accidentally enter
their pgp passphrase. That will make the mistake much less likely.
If people don't read the prompt, well, then we cannot help them either.

Thanks for pointing out how gpg-agent really works.

Stefan

Re: gpg-agent branch treats PGP passphrase as repository password?

[C. Michael Pilato]

On 12/01/2010 06:29 PM, Dan Engel wrote:
> From a purely personal point of view, I'd be happy with ANY disk or
> memory password cache for Subversion on Linux that is safe
> (security-wise) and doesn't rely on the presence of any GUI libraries or
> capabilities. The gpg-agent path was just the easiest one for me to
> implement directly.

FWIW, I appreciate that you're taking a look at this, Dan.  I know that many
corporate customers of Subversion desperately want additional encrypted
password caching options that, as you say, don't rely on GUI libraries.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: gpg-agent branch treats PGP passphrase as repository password?

[Dan Engel]

On Wed, 2010-12-01 at 14:08 +0100, Stefan Sperling wrote:
> However, I still see a potential risk here because the name
> "gpg-agent"
> is very misleading. It violates the principle of least surprise.
> How can we prevent users misunderstanding what "Subversion's gpg-agent
> feature" does from entering their private pgp key passphrase (which
> will
> then be sent to the server)?  Can we control the prompt printed by
> gpg-agent? ("Enter your Subversion password, NOT your secret PGP
> passphrase!") 


Yes, the agent protocol provides for customized prompts, and the patch
itself refers to the Subversion repository server (or something like
that) in that prompt.

I have no emotional investment in the gpg-agent idea (aside from the
"don't re-invent the wheel argument"), but here's my $0.02:

I think most people who know enough to use gpg agent (it's a bit more
involved to set up, etc. than things like gnome-keyring) probably
understand what it does well enough to not make that mistake.

Also, in most corporate or enterprise environments (where the stakes are
really high) Subversion will be installed and set up by administrators
(who *better* know what they're doing) and used by users who may not
even know that gpg-agent is running in the background. All they get is a
prompt for their subversion password.

I know those lines get a little more blurred in Linux-land than in
Windows-land, but I think the point is still a valid one.

>From a purely personal point of view, I'd be happy with ANY disk or
memory password cache for Subversion on Linux that is safe
(security-wise) and doesn't rely on the presence of any GUI libraries or
capabilities. The gpg-agent path was just the easiest one for me to
implement directly.

Thanks,
-Dan

Re: gpg-agent branch treats PGP passphrase as repository password?

[Stefan Sperling]

On Wed, Dec 01, 2010 at 06:50:35AM -0500, Dan Engel wrote:
> On Sun, 2010-10-17 at 16:03 +0200, Stefan Sperling wrote:
> > If my understanding is correct, it seems the current code on the gpg-agent
> > branch essentially uses the gpg-agent as a glorified password prompt.
> > 
> > Here's what the code seems to be doing:
> > 
> > Storing a password:
> >   Nothing happens.
> > 
> > Retreiving a password:
> > Step 1: svn contacts the gpg-agent to find out the passphrase for the 
> > private
> > PGP key the agent is managing
> 
> I have not reviewed the "current code" on the gpg-agent branch, but was
> the original submitter for the gpg-agent support patch. I've wanted to
> return to it, but have not had the time. However, I would like to take a
> moment and address this concern.
> 
> The name of the program (gpg-agent) may be misleading in this, but all
> gpg-agent does is to safely (securely, without swapping, etc.) cache
> secrets indexed by a domain. The domain is whatever the client provides
> and the secret is the password that the user types in. So what happens
> is:
> 
> Step 1: svn contacts gpg-agent, providing the username and repository
> URL as the domain.
> 
> Step 2: gpg-agent checks to see whether there is a password associated
> with that domain. If not, it prompts for one. Here, the user enters
> their subversion password, NOT their pgp private key passphrase.
> 
> Step 3: gpg-agent associates the password with the provided domain and
> stores that in the memory cache in protected memory. There is typically
> a timeout (one hour, 24 hours, whatever).
> 
> Step 4: svn receives the password and sends it to the server.
> 
> Step 5: Later, the user invokes svn again (in a way that needs the
> server). Normally, this would be the point at which svn would prompt for
> another password. Instead...
> 
> Step 6: svn contacts the gpg-agent, providing the same domain (username
> + repository URL) as before.
> 
> Step 7: gpg-agent checks to see whether there is a password associated
> with that domain, and this time there is, because of step 3 before. Now,
> gpg-agent just returns this password instead of prompting for a new one.
> 
> Step 8: svn receives the password and sends it to the server...
> 
> So, you see, in spite of the name (gpg-agent) there's no inherent
> interaction between gpg-agent and the pgp private key store, and at no
> time is the user prompted for their private pgp key.
> 
> The purpose of the gpg-agent patch is to make it so that a user who
> doesn't have one of the GUI wallets available (gnome-keyring or kwallet)
> doesn't have to type in their subversion password EVERY time they invoke
> a command against the repository. The gpg program uses gpg-agent (when
> so configured) for exactly the same purpose--to keep the user from
> having to re-type that passphrase more than once every X hours. But the
> agent itself is generic enough to serve a broad range of password
> caching needs.
> 
> gpg-agent allows the user to configure how long passwords persist in
> protected memory. If the timeout has passed, then in step 7, the
> gpg-agent would request the password again since it would no longer be
> in the memory cache.
> 
> Does that all make sense?

Thanks, this makes sense. I was expecting a scheme that would persist
the password on disk. Using gpg-agent as a mere runtime password cache
as you describe is certainly fine and, if used right, does not expose
the private key passphase.

However, I still see a potential risk here because the name "gpg-agent"
is very misleading. It violates the principle of least surprise.
How can we prevent users misunderstanding what "Subversion's gpg-agent
feature" does from entering their private pgp key passphrase (which will
then be sent to the server)?  Can we control the prompt printed by
gpg-agent? ("Enter your Subversion password, NOT your secret PGP passphrase!")

Remember that people may want to use Subversion password caches even for
publicly accessible servers which are password "protected" with a commonly
known user/password combination. Any such server could potentially receive
PGP passphrases in clear text if the gpg-agent feature is misused.

Because of this concern, I'd rather have a new tool called 'svn-agent'
for this purpose, licensed under Apache License v2 and distributed
along with Subversion. jIn that case users would not make a mental
association with PGP and are very unlikely to enter their PGP passphrase.
This would also avoid introducing a dependency on an external tool.
It would not be very hard to write such a tool, using a protocol similar
to the one used in gpg-agent.

I would also support a scheme that uses PGP in the way I described,
persisting passwords on disk encrypted with a PGP private key.

Thanks,
Stefan

Re: gpg-agent branch treats PGP passphrase as repository password?

[Dan Engel]

On Sun, 2010-10-17 at 16:03 +0200, Stefan Sperling wrote:
> If my understanding is correct, it seems the current code on the gpg-agent
> branch essentially uses the gpg-agent as a glorified password prompt.
> 
> Here's what the code seems to be doing:
> 
> Storing a password:
>   Nothing happens.
> 
> Retreiving a password:
> Step 1: svn contacts the gpg-agent to find out the passphrase for the private
> PGP key the agent is managing

I have not reviewed the "current code" on the gpg-agent branch, but was
the original submitter for the gpg-agent support patch. I've wanted to
return to it, but have not had the time. However, I would like to take a
moment and address this concern.

The name of the program (gpg-agent) may be misleading in this, but all
gpg-agent does is to safely (securely, without swapping, etc.) cache
secrets indexed by a domain. The domain is whatever the client provides
and the secret is the password that the user types in. So what happens
is:

Step 1: svn contacts gpg-agent, providing the username and repository
URL as the domain.

Step 2: gpg-agent checks to see whether there is a password associated
with that domain. If not, it prompts for one. Here, the user enters
their subversion password, NOT their pgp private key passphrase.

Step 3: gpg-agent associates the password with the provided domain and
stores that in the memory cache in protected memory. There is typically
a timeout (one hour, 24 hours, whatever).

Step 4: svn receives the password and sends it to the server.

Step 5: Later, the user invokes svn again (in a way that needs the
server). Normally, this would be the point at which svn would prompt for
another password. Instead...

Step 6: svn contacts the gpg-agent, providing the same domain (username
+ repository URL) as before.

Step 7: gpg-agent checks to see whether there is a password associated
with that domain, and this time there is, because of step 3 before. Now,
gpg-agent just returns this password instead of prompting for a new one.

Step 8: svn receives the password and sends it to the server...

So, you see, in spite of the name (gpg-agent) there's no inherent
interaction between gpg-agent and the pgp private key store, and at no
time is the user prompted for their private pgp key.

The purpose of the gpg-agent patch is to make it so that a user who
doesn't have one of the GUI wallets available (gnome-keyring or kwallet)
doesn't have to type in their subversion password EVERY time they invoke
a command against the repository. The gpg program uses gpg-agent (when
so configured) for exactly the same purpose--to keep the user from
having to re-type that passphrase more than once every X hours. But the
agent itself is generic enough to serve a broad range of password
caching needs.

gpg-agent allows the user to configure how long passwords persist in
protected memory. If the timeout has passed, then in step 7, the
gpg-agent would request the password again since it would no longer be
in the memory cache.

Does that all make sense?

Thanks,
-Dan

> Step 2: svn treats this passphrase as the repository password, and sends
> it to the server.
> 
> This is very wrong, if not outright dangerous.
> Nobody should use their PGP passphrase as a Subversion password.
> The passphrase is sacred, and svn should not ever send it to the server.
> It could be easily leaked in case someone is using http:// to connect
> to a repository, for instance. This behaviour of svn can lead to the private
> PGP key being compromised.
> 
> Here's what I think should happen instead:
> 
> Storing a password:
> Step 1: svn encrypts the password using the user's public PGP key and
> stores the encrypted form somewhere in the ~/.subversion/auth area
> 
> Retreiving a password:
> Step 1: svn contacts the gpg-agent to find out the passphrase for the
> private pgp key the agent is managing. If the agent cannot be
>   contacted svn asks the user for the passphrase.
> Step 2: svn uses this passphrase to decrypt the user's PGP private key
> Step 3: svn uses this private key to decrypt the password stored
> inside the ~/.subversion/auth area
> Step 4: svn sends the decrypted password to the server
> 
> The GPGME library will probably help with these steps:
> http://www.gnupg.org/gpgme.html
> I haven't checked, but it's possible that this library will talk to
> the GPG agent on behalf of Subversion.
> 
> Also, it could happen that the block of memory containing the passphrase
> is swapped out to disk. This should be prevented if at all possible,
> e.g. by using mlock(). The passphrase should be overwritten with random
> data right after it has been used.
> 
> The feature could be renamed from "gpg-agent password store" to
> "gpgme password store" or "pgp-encrypted password store", to take
> account of the fact that the gpg-agent itself doesn't provide encryption
> services.
> 
> I'm strongly -1 on merging the branch to trunk in its current form.
> I'm sorry I didn'

Re: gpg-agent branch treats PGP passphrase as repository password?

[Stefan Sperling]

On Mon, Oct 18, 2010 at 03:22:30PM +0530, Senthil Kumaran S wrote:
> Hi Stefan,
> 
> Stefan Sperling wrote:
> >If my understanding is correct, it seems the current code on the gpg-agent
> >branch essentially uses the gpg-agent as a glorified password prompt.
> 
> Thanks for the thorough review. I shall look into the solution you
> have mentioned and will work on those grounds to complete the
> password cache thingy. Will come up with some more sensible patch in
> the branch shortly.

Great! I wish I had time to help out, but don't have time right now :(
I will try to review commits to the branch. And feel free to catch me
on IRC or mail dev@ if you'd like a quick review of any work-in-progress
material you may have.

Thanks,
Stefan

Re: gpg-agent branch treats PGP passphrase as repository password?

[Senthil Kumaran S]

Hi Stefan,

Stefan Sperling wrote:

If my understanding is correct, it seems the current code on the gpg-agent
branch essentially uses the gpg-agent as a glorified password prompt.


Thanks for the thorough review. I shall look into the solution you have 
mentioned and will work on those grounds to complete the password cache thingy. 
Will come up with some more sensible patch in the branch shortly.


Thank You.
--
Senthil Kumaran S
http://www.stylesen.org/

gpg-agent branch treats PGP passphrase as repository password?

[Stefan Sperling]

If my understanding is correct, it seems the current code on the gpg-agent
branch essentially uses the gpg-agent as a glorified password prompt.

Here's what the code seems to be doing:

Storing a password:
  Nothing happens.

Retreiving a password:
Step 1: svn contacts the gpg-agent to find out the passphrase for the private
PGP key the agent is managing
Step 2: svn treats this passphrase as the repository password, and sends
it to the server.

This is very wrong, if not outright dangerous.
Nobody should use their PGP passphrase as a Subversion password.
The passphrase is sacred, and svn should not ever send it to the server.
It could be easily leaked in case someone is using http:// to connect
to a repository, for instance. This behaviour of svn can lead to the private
PGP key being compromised.

Here's what I think should happen instead:

Storing a password:
Step 1: svn encrypts the password using the user's public PGP key and
stores the encrypted form somewhere in the ~/.subversion/auth area

Retreiving a password:
Step 1: svn contacts the gpg-agent to find out the passphrase for the
private pgp key the agent is managing. If the agent cannot be
contacted svn asks the user for the passphrase.
Step 2: svn uses this passphrase to decrypt the user's PGP private key
Step 3: svn uses this private key to decrypt the password stored
inside the ~/.subversion/auth area
Step 4: svn sends the decrypted password to the server

The GPGME library will probably help with these steps:
http://www.gnupg.org/gpgme.html
I haven't checked, but it's possible that this library will talk to
the GPG agent on behalf of Subversion.

Also, it could happen that the block of memory containing the passphrase
is swapped out to disk. This should be prevented if at all possible,
e.g. by using mlock(). The passphrase should be overwritten with random
data right after it has been used.

The feature could be renamed from "gpg-agent password store" to
"gpgme password store" or "pgp-encrypted password store", to take
account of the fact that the gpg-agent itself doesn't provide encryption
services.

I'm strongly -1 on merging the branch to trunk in its current form.
I'm sorry I didn't see this problem during my initial review of the code.

Thanks,
Stefan