NFS version 4, SPKM-3 and SSH

I do not know NFS, unfortunately, but need to know about the new,
configurable security features. Specifically, Kerberos is a pain
in the, er, neck and we are very much an SSH shop.

It would be useful for our purposes if we could use normal SSH
authentication for NFS. I.e. file access would be allowed if and
only if the user can issue 'ssh ls' without a password or key
phrase.

This looks to be theoretically possible, but are there any reasons
why it wouldn't work?

And, if it would work, is anyone else interested or working on it?


Regards,
Nick Maclaren.

Nick Maclaren wrote:[color=blue]
> I do not know NFS, unfortunately, but need to know about the new,
> configurable security features. Specifically, Kerberos is a pain
> in the, er, neck and we are very much an SSH shop.
>
> It would be useful for our purposes if we could use normal SSH
> authentication for NFS. I.e. file access would be allowed if and
> only if the user can issue 'ssh ls' without a password or key
> phrase.
>
> This looks to be theoretically possible, but are there any reasons
> why it wouldn't work?[/color]

SPKM uses public key certificates. Are you thinking of SSH with
or without public certificates? I.e. what is normal SSH authentication?

If normal means using public key certificates on the
client and server side, then it should work, but it is a small matter
of
actually producing an SPKM GSS-API mechanism, with some kernelization.

Of course there is the small matter of boot strapping. If the
SSH private key for a user is in his home directory, and if
the home directory is itself exported with sec=spkm, then how does
a user log into his desktop system? You'd have to put the private keys
somewhere, such as in a directory, like LDAP or NIS, encrypted
with the login password, or use Kerberos.
[color=blue]
> And, if it would work, is anyone else interested or working on it?[/color]

Apparently not. I wrote the SPKM-3 RFC many years ago and
so far all there is a just a prototype from the CITI folks at
Univ. of Michigan.

In article <1115318169.315215.112160@o13g2000cwo.googlegroups.com>,
Mike Eisler <spamisevi1@yahoo.com> wrote:[color=blue]
>
>SPKM uses public key certificates. Are you thinking of SSH with
>or without public certificates? I.e. what is normal SSH authentication?[/color]

Unfortunately, I also suffer from having been in this game too long
and on the periphery of the area - i.e. I don't know what you mean
by a public key certificate, and can think of several things! Also,
I am not familiar with SSH's implementation, and the same applies.
Rather than confusing the issue by going into this, let me describe
the ways we use SSH and would like to use SPKM.

Trusted clients
---------------

The server and client have trusted files of each others public keys,
and authenticate each other. Thereafter the server trusts the
client's reference of "User X" to be its "User X".

Untrusted clients
-----------------

The user's home directory contains a trusted file of the public keys
of logins that he is prepared to trust. If the connexion is signed
using a corresponding private key, then the client is allowed access
as the user.
[color=blue]
>If normal means using public key certificates on the
>client and server side, then it should work, but it is a small matter
>of
>actually producing an SPKM GSS-API mechanism, with some kernelization.[/color]

Thanks. That is what I thought.
[color=blue]
>Of course there is the small matter of boot strapping. If the
>SSH private key for a user is in his home directory, and if
>the home directory is itself exported with sec=spkm, then how does
>a user log into his desktop system? You'd have to put the private keys
>somewhere, such as in a directory, like LDAP or NIS, encrypted
>with the login password, or use Kerberos.[/color]

Not a problem in my environment. We are serving a secondary home
directory (i.e. one that is used for supercomputing) and can assume
that they have already logged into either a desktop or departmental
system. What I would like is to give them access via NFS rather
than by logging in.
[color=blue][color=green]
>> And, if it would work, is anyone else interested or working on it?[/color]
>
>Apparently not. I wrote the SPKM-3 RFC many years ago and
>so far all there is a just a prototype from the CITI folks at
>Univ. of Michigan.[/color]

Thanks :-( Another item to add to my list, much of which is so
old that it is archived on tape! Paper tape ....


Regards,
Nick Maclaren.

Nick Maclaren wrote:[color=blue]
> In article <1115318169.315215.112160@o13g2000cwo.googlegroups.com>,
> Mike Eisler <spamisevi1@yahoo.com> wrote:[color=green]
> >
> >SPKM uses public key certificates. Are you thinking of SSH with
> >or without public certificates? I.e. what is normal SSH[/color][/color]
authentication?[color=blue]
>
> Unfortunately, I also suffer from having been in this game too long
> and on the periphery of the area - i.e. I don't know what you mean
> by a public key certificate, and can think of several things! Also,[/color]

A public key certificate adheres to the X.509 standard, and has a bunch
of
stuff including the public key of the principal, and a digital
signature
from a Certificate Authority (CAs). Your web browser should have a
list of CAs and their public certificates. Web browsers need this
stuff so that they can accept public key certificates from web sites
using SSL You may from time to time encounter web sites with
certs not signed by a CA your browser recognizes and get a relevant
pop up window alerting you to this.
[color=blue]
> I am not familiar with SSH's implementation, and the same applies.
> Rather than confusing the issue by going into this, let me describe
> the ways we use SSH and would like to use SPKM.
>
> Trusted clients
> ---------------
>
> The server and client have trusted files of each others public keys,
> and authenticate each other. Thereafter the server trusts the
> client's reference of "User X" to be its "User X".[/color]

Unless these keys are signed with the key of a CA, this isn't
compatible
with SPKM's model (which in turn is the same as SSLs model).

In article <1115392931.538848.6280@z14g2000cwz.googlegroups.com>,
"Mike Eisler" <spamisevi1@yahoo.com> writes:
|>
|> A public key certificate adheres to the X.509 standard, and has a bunch
|> of
|> stuff including the public key of the principal, and a digital
|> signature
|> from a Certificate Authority (CAs). ...

Ah, THAT one. Thanks.

|> > The server and client have trusted files of each others public keys,
|> > and authenticate each other. Thereafter the server trusts the
|> > client's reference of "User X" to be its "User X".
|>
|> Unless these keys are signed with the key of a CA, this isn't
|> compatible
|> with SPKM's model (which in turn is the same as SSLs model).

Oh, heck :-(

That model is precisely what I don't want, on many and good grounds,
though I could spoof it by describing myself as a CA and implementing
a huge amount of infrastructure to be ignored. My requirement is
that I have two systems, managed by the same 'group' (i.e. belonging
to the same security domain) connected by an untrusted network, and
would like to NFS export between them.


Regards,
Nick Maclaren.

Nick Maclaren wrote:
[color=blue]
> That model is precisely what I don't want, on many and good grounds,
> though I could spoof it by describing myself as a CA and implementing
> a huge amount of infrastructure to be ignored. My requirement is
> that I have two systems, managed by the same 'group' (i.e. belonging
> to the same security domain) connected by an untrusted network, and
> would like to NFS export between them.[/color]

How can you spoof a CA?

With public key without signed certs from CA how do you prevent a
man in the middle attack?

In article <1115405791.280141.67000@g14g2000cwa.googlegroups.com>,
Mike Eisler <spamisevi1@yahoo.com> wrote:[color=blue]
>Nick Maclaren wrote:
>[color=green]
>> That model is precisely what I don't want, on many and good grounds,
>> though I could spoof it by describing myself as a CA and implementing
>> a huge amount of infrastructure to be ignored. My requirement is
>> that I have two systems, managed by the same 'group' (i.e. belonging
>> to the same security domain) connected by an untrusted network, and
>> would like to NFS export between them.[/color]
>
>How can you spoof a CA?[/color]

Oh, THAT'S easy. Just lean on the CA administrators for root access
and hack from there. Remember that, in the UK, all major CAs are
selected/approved by the government, which has a spectacular record
for that sort of behaviour. I would never trust any organisation
trusted by a government agency :-)

But that's not what I said.

I said that I would spoof the client by describing myself as a CA.
Remember that I am the administrator of both the server and the
client (or, rather, a few trusted and collaborating colleagues are
the administrators of both).
[color=blue]
>With public key without signed certs from CA how do you prevent a
>man in the middle attack?[/color]

Transfer it by SSH?

If you are seriously worried about being hacked while initialising,
write the key onto paper, floppy disk or DVD and carry the thing by
hand to the other machine! Not a problem. Note that you have
EXACTLY the same problem with even trusted CAs - how you you get
THEIR identification securely if you are worried about being hacked
while setting up?


Regards,
Nick Maclaren.

Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:[color=blue]
> That model is precisely what I don't want, on many and good grounds,
> though I could spoof it by describing myself as a CA and implementing
> a huge amount of infrastructure to be ignored. My requirement is
> that I have two systems, managed by the same 'group' (i.e. belonging
> to the same security domain) connected by an untrusted network, and
> would like to NFS export between them.[/color]

IPSEC perhaps?

rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

In article <PLPee.5031$Hs1.3038@news.cpqcorp.net>,
Rick Jones <foo@bar.baz.invalid> wrote:[color=blue]
>Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:[color=green]
>> That model is precisely what I don't want, on many and good grounds,
>> though I could spoof it by describing myself as a CA and implementing
>> a huge amount of infrastructure to be ignored. My requirement is
>> that I have two systems, managed by the same 'group' (i.e. belonging
>> to the same security domain) connected by an untrusted network, and
>> would like to NFS export between them.[/color]
>
>IPSEC perhaps?[/color]

Oh, there's no problem about doing it securely - I have been told
that you can persuade NFS to transfer over a SSH tunnel as well.
The issue is manageability - at least for this use.

Ideally, it would be nice to use the SAME mechanisms as we use for
SSH, because they (a) allow BOTH trusted hosts and user access from
untrusted hosts (securely) and (b) are simple to manage and we are
using them anyway.

Kerberos is a pain in the **** to administer and use, and allows
only user access anyway. CA-based mechanisms involve either running
our own or trusting some third party. My understanding of IPSEC
(which could well be wrong) is that it doesn't address the problem
of authenticating the far end over an untrusted network. SSH does,
but SSH tunnels need administration work at both ends.

Does that clarify the requirement?


Regards,
Nick Maclaren.

Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:[color=blue]
> Ideally, it would be nice to use the SAME mechanisms as we use for
> SSH, because they (a) allow BOTH trusted hosts and user access from
> untrusted hosts (securely) and (b) are simple to manage and we are
> using them anyway.[/color]

Wouldn't user access from untrusted hosts "trust" that the SSL
implementation wasnt a "tee?"
[color=blue]
> Kerberos is a pain in the **** to administer and use, and allows
> only user access anyway. CA-based mechanisms involve either running
> our own or trusting some third party. My understanding of IPSEC
> (which could well be wrong) is that it doesn't address the problem
> of authenticating the far end over an untrusted network. SSH does,
> but SSH tunnels need administration work at both ends.[/color]

IIRC IPSEC includes private key mechanisms.
[color=blue]
> Does that clarify the requirement?[/color]

I might be getting there :)
[color=blue]
> Regards,
> Nick Maclaren.[/color]

--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

In article <8ySee.5043$1y1.4598@news.cpqcorp.net>,
Rick Jones <foo@bar.baz.invalid> wrote:[color=blue]
>Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:[color=green]
>> Ideally, it would be nice to use the SAME mechanisms as we use for
>> SSH, because they (a) allow BOTH trusted hosts and user access from
>> untrusted hosts (securely) and (b) are simple to manage and we are
>> using them anyway.[/color]
>
>Wouldn't user access from untrusted hosts "trust" that the SSL
>implementation wasnt a "tee?"[/color]

Well, yes, but that is unavoidable, and applies twofold to CA methods
(i.e. you are trusting BOTH your system AND the certificate authority).
You can't protect yourself against the facilities you are relying on
to ensure security! But it isn't what I meant, anyway.

In this context, "untrusted" means by the server. I.e. a user Fred
is logging on from a completely unknown client, which may be one of
his workstations, a system he is using when working in another country
or whatever. He 'quotes' Fred's key, the server looks it up in Fred's
home directory, and lets him in if it matches. The server never even
attempts to authenticate the client machine, because it is pointless.
[color=blue][color=green]
>> Kerberos is a pain in the **** to administer and use, and allows
>> only user access anyway. CA-based mechanisms involve either running
>> our own or trusting some third party. My understanding of IPSEC
>> (which could well be wrong) is that it doesn't address the problem
>> of authenticating the far end over an untrusted network. SSH does,
>> but SSH tunnels need administration work at both ends.[/color]
>
>IIRC IPSEC includes private key mechanisms.[/color]

Thanks. I will take another look. The trouble about most of those
things are that they are written purely for insiders - if you aren't
already "in the know", you have to reverse engineer their terminology
and undocumented assumptions. It would help immensely if a few more
would write a clear description of the model they are using :-(

See earlier in this thread. "Public key certificate". Well, I know
of many different things that that can describe and am not close
enough to this area to know which it is used for in THIS context.
I do now, but it is not what I had decided on ....



Regards,
Nick Maclaren.

Regards,
Nick Maclaren.

Nick Maclaren wrote:[color=blue]
> In article <1115405791.280141.67000@g14g2000cwa.googlegroups.com>,
> Mike Eisler <spamisevi1@yahoo.com> wrote:[color=green]
> >Nick Maclaren wrote:
> >[color=darkred]
> >> That model is precisely what I don't want, on many and good[/color][/color][/color]
grounds,[color=blue][color=green][color=darkred]
> >> though I could spoof it by describing myself as a CA and[/color][/color][/color]
implementing[color=blue][color=green][color=darkred]
> >> a huge amount of infrastructure to be ignored. My requirement is
> >> that I have two systems, managed by the same 'group' (i.e.[/color][/color][/color]
belonging[color=blue][color=green][color=darkred]
> >> to the same security domain) connected by an untrusted network,[/color][/color][/color]
and[color=blue][color=green][color=darkred]
> >> would like to NFS export between them.[/color]
> >
> >How can you spoof a CA?[/color]
>[/color]
[...][color=blue]
> I said that I would spoof the client by describing myself as a CA.[/color]

And what if the CA you describe yourself as is not on my client's
list of CAs? Or, what if th CA you are impersonating is on my
client's list of CAs, but when I attempt to verify your signature
on the certificate, the verification fails (because you don't know
the CA's private key.
[color=blue]
> Remember that I am the administrator of both the server and the
> client (or, rather, a few trusted and collaborating colleagues are
> the administrators of both).[/color]

If you are the administrator of both, and if your objective is to
protect your users from you, then all this crypto stuff isn't going to
protect them. It is an axiom that anyone with physical access can
compromise any security. Unless of course your users and bosses
are stupid or ignorant people that fail to understand this axiom, and
go ahead and hire inexpensive felons to administer their data, figuring
that
crypto is going to protect them.
[color=blue][color=green]
> >With public key without signed certs from CA how do you prevent a
> >man in the middle attack?[/color]
>
> Transfer it by SSH?[/color]

And how does cert-less SSH prevent a man in the middle attack?
[color=blue]
> If you are seriously worried about being hacked while initialising,
> write the key onto paper, floppy disk or DVD and carry the thing by
> hand to the other machine! Not a problem. Note that you have[/color]

Well that's certainly scalable.
[color=blue]
> EXACTLY the same problem with even trusted CAs - how you you get
> THEIR identification securely if you are worried about being hacked
> while setting up?[/color]

It's the same qualitatively, but not the same quantitatively.
If you have 100 computers and 100 users
in your network, then without CAs you have to
establish 100 user keys and 100 server key pairs on each computer, and
thus
do 20,000 instalations. If you have CAs, then you still have to
establish
200 key pairs, but only 100 server key pairsneed to be installed, and
the
100 user key pairs can be installed in a directory service, with the
private
key of each pair encrypted with a pass phrase.

In article <1115683035.780767.18630@z14g2000cwz.googlegroups.com>,
Mike Eisler <spamisevi1@yahoo.com> wrote:[color=blue]
>[color=green][color=darkred]
>> >How can you spoof a CA?[/color]
>>
>> I said that I would spoof the client by describing myself as a CA.[/color]
>
>And what if the CA you describe yourself as is not on my client's
>list of CAs? Or, what if th CA you are impersonating is on my
>client's list of CAs, but when I attempt to verify your signature
>on the certificate, the verification fails (because you don't know
>the CA's private key.[/color]

Eh? I said that I (logically I) am the administrator of both systems!
That would imply that I made an error with the configuration, so the
answer to your question is that I would fix it.
[color=blue][color=green]
>> Remember that I am the administrator of both the server and the
>> client (or, rather, a few trusted and collaborating colleagues are
>> the administrators of both).[/color]
>
>If you are the administrator of both, and if your objective is to
>protect your users from you, then all this crypto stuff isn't going to
>protect them. It is an axiom that anyone with physical access can
>compromise any security. ...[/color]

That's what I said earlier! And, NO, that is NOT the objective. As
I said, the objective is to export a file system on machine A to
machine B, both of which I manage, over a network that I don't and
which is potentially compromised. That was the problem that SSH was
designed to address, and is the problem that I have.

The problem about most of the "certificate authority" and related
solutions is that they introduce a vast complexity for features that
few people want, introduce several fundamental and unnecessary security
flaws, and make it extremely hard to provide the simple, common features
simply. Oh, I know why governments want them - it provides them with
a central point of control/snooping/whatever.
[color=blue][color=green][color=darkred]
>> >With public key without signed certs from CA how do you prevent a
>> >man in the middle attack?[/color]
>>
>> Transfer it by SSH?[/color]
>
>And how does cert-less SSH prevent a man in the middle attack?[/color]

Eh? The server has a trusted (root-owned) file with a list of the
public keys of systems that it trusts. The client encodes a recognisable
string with its private key, and the server decodes and checks it.
No third-party involved.

Also, as I said in the beginning, I have already set this up. How
on earth do YOU administer a system the other side of an untrusted
network?
[color=blue][color=green]
>> If you are seriously worried about being hacked while initialising,
>> write the key onto paper, floppy disk or DVD and carry the thing by
>> hand to the other machine! Not a problem. Note that you have[/color]
>
>Well that's certainly scalable.[/color]

It is quite adequately scalable for most purposes, and does not involve
trusting a third-party.
[color=blue][color=green]
>> EXACTLY the same problem with even trusted CAs - how you you get
>> THEIR identification securely if you are worried about being hacked
>> while setting up?[/color]
>
>It's the same qualitatively, but not the same quantitatively.
>If you have 100 computers and 100 users
>in your network, then without CAs you have to
>establish 100 user keys and 100 server key pairs on each computer, and
>thus
>do 20,000 instalations. If you have CAs, then you still have to
>establish
>200 key pairs, but only 100 server key pairsneed to be installed, and
>the
>100 user key pairs can be installed in a directory service, with the
>private
>key of each pair encrypted with a pass phrase.[/color]

Well, in common with 99% of the people who need reasonably secure NFS
export, that's not my requirement. Indeed, I have never even heard
of a real site that has operated the way that you say for very long;
managing large numbers of systems in that fashion has so many other
scalability problems that most people give up and back off to
something a lot closer to a star network.

Furthermore, you have omitted the other scalability issue. Unless I
run my own CA, I have to trust a third-party CA. But how do I get
the key from that, when I am planning to export to another university?
If there is a single CA for UK academia (thinking parochially), we
all have to beat on its doors. Well, the current thinking is that
it will delegate its authority to subsidiary CAs, so I have now got
to trust TWO third-parties, over neither of which do I have any
control. And, given the UK government's spectacular record of IT
incompetence, that is insane.


Regards,
Nick Maclaren.

Nick Maclaren wrote:[color=blue]
> In article <1115683035.780767.18630@z14g2000cwz.googlegroups.com>,
> Mike Eisler <spamisevi1@yahoo.com> wrote:[color=green]
> >[color=darkred]
> >> >How can you spoof a CA?
> >>
> >> I said that I would spoof the client by describing myself as a CA.[/color]
> >
> >And what if the CA you describe yourself as is not on my client's
> >list of CAs? Or, what if th CA you are impersonating is on my
> >client's list of CAs, but when I attempt to verify your signature
> >on the certificate, the verification fails (because you don't know
> >the CA's private key.[/color]
>
> Eh? I said that I (logically I) am the administrator of both[/color]
systems![color=blue]
> That would imply that I made an error with the configuration, so the
> answer to your question is that I would fix it.[/color]

Ok then. Spoofing a CA is not an issue.
[color=blue]
>[color=green][color=darkred]
> >> Remember that I am the administrator of both the server and the
> >> client (or, rather, a few trusted and collaborating colleagues are
> >> the administrators of both).[/color]
> >
> >If you are the administrator of both, and if your objective is to
> >protect your users from you, then all this crypto stuff isn't going[/color][/color]
to[color=blue][color=green]
> >protect them. It is an axiom that anyone with physical access can
> >compromise any security. ...[/color]
>
> That's what I said earlier! And, NO, that is NOT the objective. As
> I said, the objective is to export a file system on machine A to
> machine B, both of which I manage, over a network that I don't and
> which is potentially compromised. That was the problem that SSH was
> designed to address, and is the problem that I have.[/color]

I'm claiming that SSH without certificates is an incomplete
and non-scalable solution. But certainly SSH beats rlogin, and
SSH-style authentication for NFS would beat AUTH_SYS. But why
do half measures if something is broken?
[color=blue]
>
> The problem about most of the "certificate authority" and related
> solutions is that they introduce a vast complexity for features that
> few people want, introduce several fundamental and unnecessary[/color]
security[color=blue]
> flaws, and make it extremely hard to provide the simple, common[/color]
features[color=blue]
> simply. Oh, I know why governments want them - it provides them with
> a central point of control/snooping/whatever.[/color]

That's not what a CA does. When I issue a transaction on the Internet,
to say amazon.com, my web browser verifies that the CA that signed
Amazon's public key is one of the ones my browser trusts. There's no
routing of authentication or authorization checks to Big Brother.
[color=blue]
>[color=green][color=darkred]
> >> >With public key without signed certs from CA how do you prevent[/color][/color][/color]
a[color=blue][color=green][color=darkred]
> >> >man in the middle attack?
> >>
> >> Transfer it by SSH?[/color]
> >
> >And how does cert-less SSH prevent a man in the middle attack?[/color]
>
> Eh? The server has a trusted (root-owned) file with a list of the
> public keys of systems that it trusts. The client encodes a[/color]
recognisable[color=blue]
> string with its private key, and the server decodes and checks it.
> No third-party involved.[/color]

I'm not just concerned about attackers faking clients. There's the
issue of attacker's faking servers/

I'm on a client and I ssh into a server for the first time.
An attacker spoofs the IP address of the server (or the IP address
of the DNS server that I used to convert the server's host name to
an address).

Doesn't matter a bit if you've secured your server.

Mutual authentication matters. CA-based public key is better mutual
authentication.
[color=blue]
> Also, as I said in the beginning, I have already set this up. How
> on earth do YOU administer a system the other side of an untrusted
> network?[/color]

I'm just a simple author and software developer. :-)

But I do know that web server administrators have been doing this
with SSL and http for 10 years or so. That SSH, NFS, etc. don't
have such capabilities has nothing to do with my skills or
lack thereof as a system administrator.

In article <1115745945.167450.199570@o13g2000cwo.googlegroups.com>,
Mike Eisler <spamisevi1@yahoo.com> wrote:[color=blue]
>
>I'm claiming that SSH without certificates is an incomplete
>and non-scalable solution. But certainly SSH beats rlogin, and
>SSH-style authentication for NFS would beat AUTH_SYS. But why
>do half measures if something is broken?[/color]

And I am claiming both that "certificate authority" systems are ALSO
incomplete and non-scalable solutions, and that they INHERENTLY add
security and manageability problems that SSH-style solutions don't
have.

Yes, there are some things that CA systems can do that SSH-style
ones can't, but the downside is that you pay a hell of a lot for
facilities that are rarely wanted (and, in my case, I positively
want not to have).
[color=blue]
>That's not what a CA does. When I issue a transaction on the Internet,
>to say amazon.com, my web browser verifies that the CA that signed
>Amazon's public key is one of the ones my browser trusts. There's no
>routing of authentication or authorization checks to Big Brother.[/color]

The certificate authorities that your browser trusts ARE the Big
Brother!

Think about it. They have to be selected by a small number of central
authorities, because allowing every user to select his own CA brings
back the scalability issues that you deprecate. When I do the same
as you, I am forced (yes, forced) to trust a CA that I know is liable
to be compromised by government action. If I insist on using only
CAs that I have reason to believe are resistant to USA and UK spooks,
and I can be damn sure that companies like Amazon won't use them.
In fact, I have certain knowledge of pressure being applied to
prevent the use of such things - not that a random academic like me
is of the slightest interest to the spooks.
[color=blue][color=green]
>> Eh? The server has a trusted (root-owned) file with a list of the
>> public keys of systems that it trusts. The client encodes a[/color]
>recognisable[color=green]
>> string with its private key, and the server decodes and checks it.
>> No third-party involved.[/color]
>
>I'm not just concerned about attackers faking clients. There's the
>issue of attacker's faking servers/[/color]

You can do the check both ways round, and SSH does. Both the server
and client then know that they are talking to each other. Not an issue.
[color=blue]
>I'm on a client and I ssh into a server for the first time.
>An attacker spoofs the IP address of the server (or the IP address
>of the DNS server that I used to convert the server's host name to
>an address).
>
>Doesn't matter a bit if you've secured your server.
>
>Mutual authentication matters. CA-based public key is better mutual
>authentication.[/color]

Yes, it does, and the use of CAs closes one loophole, ignores others,
and opens another. Not a brilliant solution! What about:

How do you know that the CA isn't being spoofed? I.e. where do
you get the secure identification of the CA from?

How do you know that the name of the server you have been given
isn't a hostile site and not the friendly one you think that it is?

How do you know that the CA hasn't been compromised? Note that
this risk does not apply to SSH-style solutions.


Regards,
Nick Maclaren.