How to encrypt a symmetric key with a shared secret? I am reading this article (pdf) on the Diffie–Hellman key exchange. It states the following:


  At this point, the Diffie-Hellman operation could be considered complete. The shared secret is, after all, a cryptographic key that could encrypt traffic. But completion at this point is very rare, because the shared secret is an asymmetric key by its mathematical nature, and all asymmetric key systems are inherently slow.
  
  ...
  
  In most real applications of the DH protocol (SSL, TLS, SSH, and IPSec in particular), the shared secret encrypts a symmetric key for one of the symmetric algorithms, then transmits it securely, and the distant end decrypts it with the shared secret.


I'm trying to understand the point in an authentication scheme where two parties have exchanged keys with Diffie-Hellman, and now have the "shared secret".


How is the shared secret asymmetric if the "shared secret" is used to both encrypt and decrypt? 
How exactly do i encrypt an AES key with the "shared secret" key?
Is it not possible to directly create a symmetric AES key with the DH key exchange?
How is the shared secret asymmetric if the "shared secret" is used to
  both encrypt and decrypt?


By its way of creation you can call it asymmetric. There are asymmetric public keys involved in agreeing on the shared secret, so it's asymmetric. You could also call it asymmetric as the knowledge of the shared secret is asymmetric. Only the endpoints know the shared (private) secret while everybody else (in the middle, like ISPs) only knows the public keys.


  How exactly do i encrypt an AES key with the "shared secret" key?


Usually, you don't. You feed the shared secret into something called a "key-based key derivation function" (KBKDF), which will accept your shared secret (a large number) and generate cryptographic keys (for use with AES for example) from that. 


  Is it not possible to directly create a symmetric AES key with the DH
  key exchange?


You could do it. However, AES accepts at most 256-bit long keys. If you end on a 256-bit shared DH secret, then the group parameters are really weak and it's easy to find the shared secret just given the public keys.