First, realize that PBKDF2 is PKCS #5 is RFC 2898, i.e. http://www.ietf.org/rfc/rfc2898.txt
It's essentially an algorithm to securely hash a password as many times as you want, with whatever hash you want. OWASP recommends hashing the password at least 64,000 times in 2012, and doubling that every two years, per https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
Note that storing (also in cleartext) a variable number of iterations per user also helps. Instead of always running PBKDF2 64,000 time, instead generate a random salt, and a random number I between 1 and 20,000. Run PBKDF2 64,000 + I times for that particular username. This makes cracking it just a little more difficult, and may prevent certain optimizations in cracking code from being useful.
Actually we use the derivation function together with the salt to provide resistance against the dictionary attacks, RIGHT?
Essentially - we salt the cleartext passphrase prior to hashing it.
My first question : ... usually the salt is stored un-encrypted, right?
In simpler implementations, a long (8 bytes or more), cryptographically random salt is stored unencrypted and regenerated with every password change. OWASP (link above) recommends additional precautions including having an additional salt stored in a config file somewhere (i.e. not stored in the database), another portion hardcoded in the source code, and storing the per-user salt in a different location than the password, perhaps a flat file vs. a database (or vice versa). Note this ideally also requires passwords and salts be backed up to different locations as well - the goal is to make it harder to steal both salts and passwords with one theft.
Also, we have the same scenario : we have the password and we want to generate a new key ... Until now, I didnt find anywhere explaining if the result of the function (the actual key( it is stored or not?
That depends. If you're using PBKDF2 to generate a key for realtime encryption during this session only, then no, it should stay in memory only, and be discarded at the end. If you're using PBKDF2 to generate a hash (after N iterations) to authenticate a user later, then you must save that hash.
I know is make it harder for dictionary attacks but if someone get access to the card i store it then we are in the first where the only precaution is the length of the password right
No, the only precaution is the strength of the password. "P@ssw0rdP@ssw0rdP@ssw0rd" is a bad password, even if it is 24 characters long and "complex". If you're going to be "registering" users, or letting them choose passwords, you need to reject any password in the most common cracking dictionaries. Further, when you're testing for rejection, you need to apply the same kind of rules that rules based dictionary crackers like Elcomsoft or Hashcat use - translate to 1337 speak, add 1 to 1000 after it, add random characters to the front and back, double it, etc. This is thankfully easier on the front end, since you can simply reverse-translate 1337 speak and lowercase it, so both P@ssw0rd and Passw0rd end up as "password", which should be filtered out as horrible. Melinda2006 is always a bad password, as is 12345.
Also, given the password how do we know if the password is the right password in order to derive the actual key?
You don't know beforehand; you just try it. If it works, it was right. If it doesn't work, it was wrong. Now, by "works", again, it depends.
For realtime decryption, you'd attempt to decrypt the message; you would then compare the HMAC you saved with the message (prior to encryption) with the values; if the HMAC doesn't match, it's a forgery, part of the message was altered, you have a bug, or the password was wrong.
For authentication, you collect the salt value that should have been used, and then re-hash the password the same number of times. If you get the same hashed result, the input must have been the same, and so it was right.