> 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:

* https://www.rfc-editor.org/rfc/rfc5869

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.)