NFS version 4, SPKM-3 and SSH - NFS

This is a discussion on NFS version 4, SPKM-3 and SSH - NFS ; 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 ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: NFS version 4, SPKM-3 and SSH

  1. 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.

  2. Re: NFS version 4, SPKM-3 and SSH


    Nick Maclaren wrote:
    > 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?


    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.

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


    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.


  3. Re: NFS version 4, SPKM-3 and SSH

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


    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.

    >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.


    Thanks. That is what I thought.

    >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.


    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.

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

    >
    >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.


    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.

  4. Re: NFS version 4, SPKM-3 and SSH


    Nick Maclaren wrote:
    > In article <1115318169.315215.112160@o13g2000cwo.googlegroups. com>,
    > Mike Eisler wrote:
    > >
    > >SPKM uses public key certificates. Are you thinking of SSH with
    > >or without public certificates? I.e. what is normal SSH

    authentication?
    >
    > 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,


    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.

    > 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".


    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).


  5. Re: NFS version 4, SPKM-3 and SSH


    In article <1115392931.538848.6280@z14g2000cwz.googlegroups.co m>,
    "Mike Eisler" 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.

  6. Re: NFS version 4, SPKM-3 and SSH


    Nick Maclaren wrote:

    > 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.


    How can you spoof a CA?

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


  7. Re: NFS version 4, SPKM-3 and SSH

    In article <1115405791.280141.67000@g14g2000cwa.googlegroups.c om>,
    Mike Eisler wrote:
    >Nick Maclaren wrote:
    >
    >> 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.

    >
    >How can you spoof a CA?


    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).

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


    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.

  8. Re: NFS version 4, SPKM-3 and SSH

    Nick Maclaren wrote:
    > 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.


    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...

  9. Re: NFS version 4, SPKM-3 and SSH

    In article ,
    Rick Jones wrote:
    >Nick Maclaren wrote:
    >> 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.

    >
    >IPSEC perhaps?


    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.

  10. Re: NFS version 4, SPKM-3 and SSH

    Nick Maclaren wrote:
    > 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.


    Wouldn't user access from untrusted hosts "trust" that the SSL
    implementation wasnt a "tee?"

    > 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.


    IIRC IPSEC includes private key mechanisms.

    > Does that clarify the requirement?


    I might be getting there

    > Regards,
    > Nick Maclaren.


    --
    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...

  11. Re: NFS version 4, SPKM-3 and SSH

    In article <8ySee.5043$1y1.4598@news.cpqcorp.net>,
    Rick Jones wrote:
    >Nick Maclaren wrote:
    >> 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.

    >
    >Wouldn't user access from untrusted hosts "trust" that the SSL
    >implementation wasnt a "tee?"


    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.

    >> 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.

    >
    >IIRC IPSEC includes private key mechanisms.


    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.

  12. Re: NFS version 4, SPKM-3 and SSH


    Nick Maclaren wrote:
    > In article <1115405791.280141.67000@g14g2000cwa.googlegroups.c om>,
    > Mike Eisler wrote:
    > >Nick Maclaren wrote:
    > >
    > >> 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.

    > >
    > >How can you spoof a CA?

    >

    [...]
    > I said that I would spoof the client by describing myself as a CA.


    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.

    > 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).


    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.

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

    >
    > Transfer it by SSH?


    And how does cert-less SSH prevent a man in the middle attack?

    > 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


    Well that's certainly scalable.

    > 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?


    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.


  13. Re: NFS version 4, SPKM-3 and SSH

    In article <1115683035.780767.18630@z14g2000cwz.googlegroups.c om>,
    Mike Eisler wrote:
    >
    >> >How can you spoof a CA?

    >>
    >> I said that I would spoof the client by describing myself as a CA.

    >
    >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.


    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.

    >> 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).

    >
    >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. ...


    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.

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

    >>
    >> Transfer it by SSH?

    >
    >And how does cert-less SSH prevent a man in the middle attack?


    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?

    >> 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

    >
    >Well that's certainly scalable.


    It is quite adequately scalable for most purposes, and does not involve
    trusting a third-party.

    >> 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?

    >
    >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.


    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.

  14. Re: NFS version 4, SPKM-3 and SSH

    Nick Maclaren wrote:
    > In article <1115683035.780767.18630@z14g2000cwz.googlegroups.c om>,
    > Mike Eisler wrote:
    > >
    > >> >How can you spoof a CA?
    > >>
    > >> I said that I would spoof the client by describing myself as a CA.

    > >
    > >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.

    >
    > 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.


    Ok then. Spoofing a CA is not an issue.

    >
    > >> 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).

    > >
    > >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. ...

    >
    > 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.


    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?

    >
    > 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.


    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.

    >
    > >> >With public key without signed certs from CA how do you prevent

    a
    > >> >man in the middle attack?
    > >>
    > >> Transfer it by SSH?

    > >
    > >And how does cert-less SSH prevent a man in the middle attack?

    >
    > 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.


    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.

    > 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?


    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.


  15. Re: NFS version 4, SPKM-3 and SSH

    In article <1115745945.167450.199570@o13g2000cwo.googlegroups. com>,
    Mike Eisler wrote:
    >
    >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?


    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).

    >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.


    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.

    >> 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.

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


    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.

    >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.


    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.

+ Reply to Thread