Yeah, the question is something like "A customer wants to to secure their communications with <company> but the customer can only use a DES crypto system and does not have a shared DES key with <company>. How can they securely communicate without help from a third party?"
Well, the customer could call the company and arrange for a meeting with a representative. After meeting the representative and verifying that they're really working for the company, the customer should hand the representative a note (or a thumb drive) with a randomly chosen DES key on it, saying "Here, use this to communicate securely with me."
(Actually, they should hand the representative two or three DES keys, and tell them to use triple DES, since a single DES key is too short to resist brute force attacks nowadays.)
If the customer and the company representative cannot physically meet, they could perhaps use e.g. the Diffie–Hellman key exchance protocol to obtain a shared secret value, and then each feed it to a key derivation function to turn it into a shared (triple) DES key. However, Diffie–Hellman alone is not secure against active man-in-the-middle attacks — without some kind of a previously shared secret, there's no way for the customer and the company rep to know for sure that they've really swapped keys with each other, rather than each of them having exchanged keys with some third party who intercepted the original Diffie–Hellman exchange (and keeps intercepting their subsequent communications to decrypt, read, re-encrypt and relay any messages).
If the customer and the company do have some kind of a shared secret — say, a password — then it's possible for them to use a password-authenticated key exchange to "upgrade" the password to a shared (triple) DES key. One fairly simple way would be for them to first do a normal anonymous D–H key exchange, but then concatenate the resulting shared secret value value with the password and feed it through a deliberately slow key derivation function to turn it into (triple) DES keys. This ensures that, if a middle-man who doesn't know the password tries to intercept the key exchange, they will not be able to derive a matching DES key with either party.
(This simple protocol does have the weakness that the middle-man, having spoofed the D–H key exchange and intercepted at least one DES-encrypted message using the correctly derived key, now has enough information to mount an offline brute force attack against the password. The security of this scheme is thus entirely dependent on the strength of the password and the slowness of the KDF. At the very least, the customer and the company should minimize the attack surface by only using this protocol once, to exchange proper shared keys, and not repeating it later; better yet, they should use a more advanced PAKE protocol that uses an interactive zero-knowledge proof to convince the authenticating parties that they both have the same password and D–H key.)
Depending on the additional assumptions we may make, there can be other options as well. For example, if the company has a private asymmetric encryption key, and the customer knows the corresponding public key, then the customer can simply generate a random (triple) DES key, encrypt it using the public key, and send the encrypted key to the company, knowing that, even if it's intercepted, only the correct recipient can decrypt it.
(Of course, this only lets the customer know that they're talking to the right company; it doesn't help the company know that the customer is really who they say they are, since the public key, being public, could presumably be used by anyone. Also, it presumes that the customer somehow already knows that the public key they have really belongs to the company, and not to an attacker.)
Even if the company only has a private key for a digital signature algorithm, there are still ways it could be used to securely establish a shared (triple) DES key. For example, the customer and company could start with a D–H key exchange, as above, and company could then sign their D–H secret value (preferably after hashing it, to make sure the signature leaks no information about the key) and send the signature (over the DES-encrypted channel) to the customer, who verifies it using the public half of the company's signing key.
In any case, my point is that this problem really has nothing to do with DES as such. It's really a key-agreement problem, and the solution depends on what kind of existing shared information the customer and the company have (and what kinds of additional tools, besides DES, they many use). If they really know nothing about each other that an attacker could not spoof, then the problem is strictly speaking unsolvable: if the customer has no way to tell if they're talking to the right company, an attacker can just intercept the customer's messages and reply to them, pretending to be the company.