From my reading on crypto.stackexchange.com I understand that HKDF is probably a better function to use for deriving EncKey and AuthKey then PBKDF2 but in the development environment I'm in (.Net) I don't have access to HKDF from an authoritative source.
Discretion is the better part of valor, so more often than not it makes sense to try and use algorithms your environment provides over having to implement your own. In this case, however, I think we have a reasonable exception; if your environment provides PBKDF2, and thus presumably HMAC, I think HKDF is simple enough that I'd say just write your own implementation of it. The most useful source is the RFC:
In particular, if your MasterKey is already uniformly distributed, section 3.3 tells you that you can skip the HKDF-Extract function (section 2.2) and implement just the HKDF-Expand (section 2.3), which is little more than a fairly straightforward chain of HMAC calls:
HKDF-Expand(PRK, info, L) -> OKM
Options:
Hash a hash function; HashLen denotes the length of the
hash function output in octets
Inputs:
PRK a pseudorandom key of at least HashLen octets
(usually, the output from the extract step)
info optional context and application specific information
(can be a zero-length string)
L length of output keying material in octets
(<= 255*HashLen)
Output:
OKM output keying material (of L octets)
The output OKM is calculated as follows:
N = ceil(L/HashLen)
T = T(1) | T(2) | T(3) | ... | T(N)
OKM = first L octets of T
where:
T(0) = empty string (zero length)
T(1) = HMAC-Hash(PRK, T(0) | info | 0x01)
T(2) = HMAC-Hash(PRK, T(1) | info | 0x02)
T(3) = HMAC-Hash(PRK, T(2) | info | 0x03)
...
(where the constant concatenated to the end of each T(n) is a
single octet.)
