On Mon, 28 Feb 2000, Niels Provos wrote: > This thread was about how default configurations can have negative > impact on security. You mention the CheckHostIP option in OpenSSH. > CheckHostIP defaults to 'yes'. It introduces only additional checks > and has not influence on permitting an SSH session to proceed. Thus it > has no negative impact on your system security. Please see below for a more detailed discussion of this issue. > I do not agree with your assumption that most SSH servers use dynamic > IP addresses. I believe that for the majority of users the contrary > is true. However, if you are in an environment with dynamic IP > addresses, you can turn the CheckHostIP option off. I did not assume that most SSH servers use dynamic IP addresses--what I did assert is that the number of servers using dynamic IP addresses will increase due to a number of factors, not least the increased access to broadband connectivity in the US, and the increase in use of personal UNIX operating systems. Many of the traditional static IP environments are also converting to dynamic allocation due to improved ease of management, as well as limited address space. Our security tools should be developed with this increasingly common environment in mind, and make use of defaults that are appropriate for that environment. Keep in mind also that a gradual introduction of IPv6 is occurring in a number of frameworks--not so much in the UIS, but certainly in other less IP-rich parts of the world. IPv6 not only assumes renumbering, but in fact one of the goals is to make this much easier. In IPv4 with CIDR, as in IPv6, the IP address has to do with packet routing, identifying interfaces, not services on hosts. > In message <Pine.NEB.3.96L.1000225211428.18984A-100000at_private>, Robe > rt Watson writes: > >You can even imagine DNS-based spoofing causing some problems, if combined > >with IP spoofing, as ssh-by-ip to a spoofed host would not generate an > >unknown key warning, instead, it would connect with full trust. This > >attack is a little of a stretch on convenience for the attacker, but is > >feasible. > This is not true. If you did not authorize a (canonical hostname, > public key) binding [by inserting it into OpenSSH's knownhosts file], > you will always get a warning. Please verify your facts before you > post. We probably ought to take this discussion to another forum more specific to SSH, but I'll give a brief overview of my concerns as they rally reflect on any user-managed key type of environment--be it PGP email, SSH, etc. The first concern is to clearly articulate the levels of warnings supported by SSH. Not being intimately familar with its construction, I have observed three types of warnings: 1) Warning, without confirmation, some administrative function has occurred 2) Warning, with confirmation, that a new key will be introduced 3) Warning, with confirmation, that a key mismatch has been observed When I observed that certain classes of key bindings could be instantiated without warning the user, I meant that user confirmation was not required to expand the scope of ``addresses'' that the key would be accepted for. While OpenSSH does display a clear warning that it has introduced a new key binding for the IP address of an existing Name->Key binding, it does not request confirmation--it automatically instantiates the binding. This creation of a binding, without requiring user confirmation, relies on a static relationship between names and IPs. You claim that it introduces no new security risks, but I see two: first, that it will introduce spurious errors (type 3 from above) in a legitimate dynamic IP environment. Second, it will allow the introduction of new bindings based on IP and DNS spoofing. Both of these have their risks: the first set of spurious warnings reduces sensitivity among the user community to the risks of changing keys--it may also require users to make key administration decisions that they are not qualified to make--either because they do not understand the issues sufficiently, or because they do not have sufficient knowledge of the server infrastructure to validate the correctness of the change. The second risk may take advantage of the first issue, but does not have to. Imagine that users may log into services based on either a name or an IP address, depending on their needs. Users expect that SSH will prompt for user confirmation during key introduction situations, and if no confirmation is required at that time, then key validation has already occurred. Essentially that the known_hosts keyring reflects their validation decisions of the past. Using the automatic key introduction technique, with DNS and IP spoofing, I can introduce new key bindings into the key set that may result in this assumption being incorrect. Suppose I pursuade a user to connect to my server by name, and they validate the key finger print. My key is now in their known_hosts, in a valid way. If I spoof DNS and IP, I can cause OpenSSH to introduce bindings between my key and arbitrary IP addresses (assuming the IP addresses aren't already in the file). If the user now attempts to connect to one of those IP addresses for a legitimate service, and spoof IP connectinos from that IP, OpenSSH will not be in the desired situation of prompting for new key introduction, but instead will use the existing key without any warning. A non-fatal advisory warning was displayed during the attack, whereas my belief is that it should have required user intervention as it created a new service address->key binding. The moral of the story seems to be that key bindings should be introduced in two situations: based on specific user confirmation of the binding creation by providing a fingerprint, etc, or through a trusted key introduction method such as a PKI the user has already authorized. Automated introduction of keys in other ways may not be appropriate in many environments, as it can generate spurious errors (key mismatches), or can increase risk by creating the opportunity for the key management mechanism to act in ways not parallel to the user's security assumptions. You can postulate that the real problem here has to do with service naming and namespaces. The user isn't interested in the binding between transport addresses and keys, only service names and keys. As transport management and service name management may be substantially different (well-known and published allocation vs. automatic and dynamic allocation), differences between the two namespaces should be respected. If the user approves a key binding between a service name in one layer, and the service, they may not be approving a binding between a name in another layer and the service. A comparable issue in another space would be creating new bindings between PGP keys and alternative forms of an address automatically. For example, just because I have a PGP key associated with my email address, robertat_private, doesn't mean PGP should assume that the PGP key is appropriate for robertat_private In PGP, as I believe it should be the case in SSH, unless a PKI is authorized to introduce new name->key bindings, bdingins are individually authorized (web of trust, whatever). There are also some practical management considerations. With centralized key files based on names, OpenSSH will replicate the central keys into personal key files for the IP bindings. If servers are renumbered, the old IP->key beindigns will persist, causing spurious errors following a renumbering of server IPs. As address space limits becmoe more pressing, this kind of situation will come up more frequently. We should take further discussion offline from a bugtraq perspective--please send replies to me and the OpenSSH mailing list. Robert N M Watson robertat_private http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:38:26 PDT