Defending hybrid encryption schemes against padding oracle attacks

I intend to use a generic integrated/hybrid encryption scheme for transmitting information between a client and a server.

Key encapsulation: a 128-bit symmetric key is generated and asymmetrically encrypted.

Data encapsulation: a 96-bit IV is generated, the plaintext is encrypted with AES-GCM using the generated key and IV. The IV is prepended to the ciphertext.

The key is disposed of at the end of transmission and never reused. The response to the client is not a decipherment of the ciphertext.

It is my understanding that the encapsulated data portion isn't susceptible to padding oracle attacks by virtue of it being based on authenticated encryption.

I am concerned about key encapsulation, though:
1) is RSA-OAEP susceptible to padding oracle attacks?
2) if I were to use textbook RSA encrypt the concatenation of the key its MAC, would that be better or worse than RSA-OAEP?
3) which elliptic curve based asymmetric encryption scheme is adequate for my use case?

Thanks!

This 2001 paper(.ps) describes a variation on DHIES that provides PKAE (public key authenticated encryption).

The scheme is called DHETM:
1) A shared secret key is derived from client and server key pairs.
2) The key is halved into an encryption key and mac key.
3) We encrypt, then MAC

Any third party attempt to forge requests will almost certainly fail MAC verification.

Is this scheme accepted as secure?
Is this DLP/EC scheme preferable to RSA for the purposes I describe?

To sum things up so far:
1) Being based on DH, DHETM as I described it is indeed public key cryptography but can't really be considered asymmetric encryption -- The sender doesn't blind itself to the content of the message after encryption.
2) @CodesInChaos suggests (noise boxes)[https://github.com/trevp/noise/wiki/Overview] as an NaCl-inspired one-way encryption
3) @RichieFrame suggests encrypting a block-sized random message and forgoing padding. The symmetric key is derived by hashing the message down to the desired size. Is EC ElGamal adequate for this purpose?

-
If your key is the same size as the asymmetric private key, you should not need any padding, and thus bypass the issue. Say by using a 512-bit elliptic curve on a 512-bit value, then hashing the decrypted value with SHA-256 to get your symmetric key. –  Richie Frame Mar 26 '14 at 9:04
I don't know if that paper's scheme is "accepted as" secure, but it's not secure, since anyone who $\hspace{.23 in}$ learns the sender's private key can trivially find the plaintexts for any ciphertext created by the sender. $\hspace{.24 in}$ –  Ricky Demer Mar 26 '14 at 11:42
@RickyDemer Well that's embarrassing... thanks for pointing this out. I must have misunderstood the scheme or the problem it aims to solve. –  nadavwr Mar 26 '14 at 14:01
@RichieFrame Thanks Richie. I'll try this approach. I wonder what NaCl and Keyczar do for public-key authenticated encryption (which they both address). I think Keyczar is RSA only. –  nadavwr Mar 26 '14 at 14:05
@RickyDemer I don't think you can call it insecure per-se since the sender's private key is assumed to be secret. What you expect is a form of forward secrecy for the sender's side. Noise boxes on the other hand provide the property you want: "Noise boxes are "one-way" - they can be decrypted by the receiver, but not the sender." –  CodesInChaos Mar 26 '14 at 14:24