RE: Something Stronger than a Passphrase? (UNCLASSIFIED)
Classification: UNCLASSIFIED
Caveats: NONE
Jim,
> -----Original Message-----
> From: Jim Basney [mailto:jbasney@ncsa.uiuc.edu]
> Sent: Tuesday, April 10, 2007 4:18 PM
> To: Friedrichs, Paul D CTR DISA PEO-IAN
> Cc: myproxy-users@ncsa.uiuc.edu
> Subject: Re: Something Stronger than a Passphrase? (UNCLASSIFIED)
>
> Friedrichs, Paul D CTR DISA PEO-IAN
> <Paul.Friedrichs.ctr@disa.mil> wrote:
> > I am *very* interested in deploying MyProxy on a large scale,
>
> Great!
>
> > but I am
> > concerned about the possibility of a phishing/pharming-like
> attack to
> > capture the passphrase passed from the prospective proxy to what it
> > thinks is the MyProxy server during the get process. What I
> don't like
> > about this is that if the prospective proxy were fooled
> into revealing
> > the passphrase here, it would be the principal who is
> harmed. Should I
> > not be concerned about this? Am I missing something?
>
> The MyProxy protocol requires the client to verify the
> server's identity via TLS before sending the passphrase.
>
> However, in general, yes, you should always be concerned
> about sending/delegating credentials to another party. The
> use of one-time, short-lived, or otherwise restricted
> credentials is one technique for managing this risk.
Last night, I regretted not pre-empting the obvious answer by saying
that I do understand that the prospective proxy is "required" to
authenticate the MyProxy server using server-authenticated SSL. But, for
example, server-authenticated SSL doesn't seem have done much to stop
phishing and pharming attacks on the Internet. The same challenge
applies here, I think (except that the secrets are one-time and must be
used immediately).
> > Given the use of PKI everywhere else, I am surprised a
> passphrase is
> > used for this process. Is it possible for the principal to
> use the put
> > command to give the MyProxy server the prospective proxy's
> public key
> > (which the principal can obtain from its SSL session with the
> > prospective proxy) and then for the MyProxy server, in the get
> > process, to authenticate the prospective proxy using this
> public key
> > and client-authenticated SSL?
>
> Yes, this is accomplished via the 'myproxy-init
> --retrievable_by' and 'myproxy-init --retrievable_by_cert' options.
Cool!
Please forgive me for not reading (or even finding) this manual before
posting my question. I was hoping, first, to understand the protocol
between the MyProxy client and server, from which I could understand
what is possible. The "protocol spec" I found did not have much detail
and would not support the functionality implied by the command options
you mention. Is there a better spec than
http://grid.ncsa.uiuc.edu/myproxy/protocol/?
I may not be able to assume common implementations of clients and
perhaps not even of servers. We would have to require client behavior as
seen by servers and server behavior as seen by clients. And we would
want each stakeholder to understand his challenges.
BTW, I notice at
http://www.globus.org/toolkit/docs/4.0/security/myproxy/rn01re01.html#id
2541716 that the Globus toolkit myproxy-init supports 'myproxy-init
--retrievable_by' but not, apparently, 'myproxy-init
--retrievable_by_cert'.
> In addition to passphrase and certificate-based
> authentication, MyProxy supports Kerberos and a variety of
> other authentication mechanisms via the PAM and SASL
> standards, such as one-time password tokens.
>
> > And this leads me to wonder... Since the principal already
> knows how
> > to issue a proxy certificate and the prospective proxy
> already knows
> > how to obtain a proxy certificate, what is the advantage of
> having a
> > MyProxy server as an intermediary? Why couldn't the principal just
> > issue a proxy certificate to the proxy?
>
> It's not always feasible to perform delegation over existing,
> implemented protocols (such as with standard web browsers),
> requiring an indirect delegation approach.
>
> MyProxy provides flexibility in the time and location of
> delegation. I can delegate a credential from my laptop to
> the MyProxy server, then later delegate that credential to a
> job on a supercomputer via the web browser on my mobile phone
> through a web portal interface.
I like it.
> I may prefer to store my PKI credentials on a
> professionally-managed MyProxy server rather than my desktop,
> laptop, or mobile phone, for both security and ease-of-use reasons.
I agree.
> I may prefer to have MyProxy delegate short-lived, restricted
> credentials to my jobs on the grid, on demand, without
> requiring me to closely watch over the jobs all the time
> myself or to delegate longer-lived, less restricted
> credentials directly to the jobs.
... or even to be on-line at the time. You've sold me :-)
> I can rely on MyProxy to
> log all activity, which can be monitored by dedicated
> security personnel and IDSs.
>
> MyProxy provides functionality that is sometimes useful,
> sometimes not.
> Certainly there are scenarios where I can manage my
> credentials myself (on a smartcard, for example) and can
> delegate them directly to services to act on my behalf,
> without needing MyProxy.
Our users already have certs with private keys on smart cards. We
already have card readers and middleware widely deployed, PKI
smartcard-based network logon required for most users, most web servers
requiring client-authenticated SSL and many other applications requiring
digital signature or PKI-based authentication. (But we still have a long
way to go.)
With proxy certs, I am hoping to address a part of the general N-tier
problem. (I say "a part of" because not all relying parties would accept
proxy credentials. I'm sure you folks have been thinking about this for
years: One cannot, for example, write a power of attorney allowing
someone else to use your driver's license to drive and expect it to
succeed. And an N-tier problem may be that the back end resource doesn't
know whether to trust an intermediary to give a response only to the
named entity. Proxy certs seem to me to be exactly analogous to powers
of attorney with the same business limitations. Necessary but
insufficient.)
So, if I have this right, it sounds like I might want users to
"myproxy-init --retrievable_by_cert dn --no_passphrase," and for
prospective proxies to "myproxy-logon --no_passphrase," and for MyProxy
servers to SSL client authenticate both users and prospective proxies.
Does this make sense? I get the impression my "myproxy-init
--retrievable_by_cert dn --no_passphrase" would force me to put a new
credential every time I want to use a new application proxy. Should the
user, above, not include "--no_passphrase," not ever give the passphrase
to prospective proxies and only use the passphrase in subsequent
commands to modify who can retrieve proxy certs?
Thanks again,
Paul
Classification: UNCLASSIFIED
Caveats: NONE